GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

From: Philipp <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alan <at> idiocy.org, mattiase <at> acm.org, 45198 <at> debbugs.gnu.org, stefankangas <at> gmail.com, joaotavora <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Sat, 17 Apr 2021 18:10:14 +0200

> Am 17.04.2021 um 17:57 schrieb Eli Zaretskii <eliz <at> gnu.org>:
> 
>> From: Philipp <p.stephani2 <at> gmail.com>
>> Date: Sat, 17 Apr 2021 17:44:06 +0200
>> Cc: João Távora <joaotavora <at> gmail.com>,
>> 45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
>> Stefan Monnier <monnier <at> iro.umontreal.ca>, Alan Third <alan <at> idiocy.org>
>> 
>>> It works and can be pushed right away but it would be nice to have a place to use it, for validation and for tuning the interface. Any plans for that?
>>> 
>> 
>> I think it would be better to first implement the mechanism and not the high-level `sandbox-enter' function (I think that one needs a bit more discussion), and implement the mechanism as a command-line flag.
> 
> IMO, if we have no reasonably clear idea how this will be used on the
> high level,

I have a relatively clear idea how I want the high-level interface to look like:

(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.

If that's OK with everyone, then I'm happy to write the code for it.

Previous Next

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