bug#45198: 28.0.50; Sandbox mode

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I don't think such an approach can work. It assumes perfect knowledge
> about anything that might be problematic, and also assumes that all
> future changes to Emacs take the sandbox question into account.
> Especially the latter point seems unrealistic, and this looks like a
> security incident waiting to happen.

That's true for the implementation side.
How 'bout the ELisp API side?

> Sandboxing is good, but it should happen using an allowlist and
> established technology, such as firejail/bubblewrap/Google sandboxed
> API/...

I'm all for it, *but*:
- I suspect we'll still want to use the extra "manual" checks I put in
  my code (so as to get clean ELisp errors when bumping against the
  walls of the sandbox, and because of the added in-depth security).
- This will need someone else doing the implementation.
- The ELisp-level API should not depend on the specific implementation
  too much, since none of those established technologies sound like
  things that'll still be maintained 10 years from now.
- We need to have this in Emacs-28 if we want to enable flymake-mode in
  ELisp by default in Emacs-28 (which I sure would like to do).
- I'd like to have this yesterday in order to build the Info files of
  GNU&NonGNU ELPA packages from their .org documentation without having
  to store the Info in the Git branch nor having to maintain some LXC
  container just for that.


        Stefan