GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Alan Third <alan <at> idiocy.org>, 45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>, João Távora <joaotavora <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Sat, 17 Apr 2021 21:19:37 +0200

Am Sa., 17. Apr. 2021 um 19:48 Uhr schrieb Mattias Engdegård <mattiase <at> acm.org>:
>
> 17 apr. 2021 kl. 18.10 skrev Philipp <p.stephani2 <at> gmail.com>:
>
> > (cl-defun start-sandbox (function &key readable-directories stdout-buffer) ...)
> > (defun wait-for-sandbox (sandbox) ...)
> >
> > where start-sandbox returns an opaque sandbox object running FUNCTION that wait-for-sandbox can wait for.  That should be generic enough that it's extensible and implementable on several platforms, and doesn't lock us into specific implementation choices.
>
> That's probably a nice interface. A slightly more low-level mechanism is what I had in mind, a `make-process` variant that starts an Emacs subprocess with the required arguments to set up a sandbox and leaving it to the user to supply remaining arguments. But maybe we are really talking about more or less the same thing.

Yes, that would essentially be how start-sandbox would get
implemented. In the Seccomp case, something like (conceptually)
(start-process "bwrap ... -- emacs --seccomp=... --quick --batch
--eval=FUNCTION")
where bwrap can set up mount namespaces to restrict the filesystem.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.