GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: Philipp <p.stephani2 <at> gmail.com>
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: Fri, 17 Sep 2021 14:13:48 +0200

[Message part 1 (text/plain, inline)]

So far the discussion has been focussed on platform-dependent low-level sandbox implementation. I took a stab at writing something that can be used by portable code.

It's basically versions of `call-process` and `make-process` specialised for running batch-mode Emacs in a sandbox. The attached patch is a straw man proposal but that should serve as a starting point for agreement on what the interface might look like.

It's only been "tested" on macOS, and there will of course be ERT tests as well before it's ready. Everything can be changed.

The idea is to have something that could be used from alpa-admin.el or similar, and for running background Elisp byte-compilation.

It uses `make-process` rather than the simpler `start-process` for running an asynchronous Emacs because the former seemed to give greater control. There is currently only one sandbox parameter: the list of directories to make available for reading. Maybe there should be a list of writable directories as well?

We could also consider higher-level primitives, for example something that takes a Lisp expression to evaluate and returns the Lisp result, taking care of the intermediate printing and reading.

[0001-platform-independent-sandbox-interface.patch (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

Previous Next

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