GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

Message #308 received at 45198 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <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 <stefan <at> marxist.se>, Philipp <p.stephani2 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Date: Tue, 13 Sep 2022 13:53:50 +0100

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

On Tue, Sep 13, 2022, 13:37 <mattiase <at> acm.org> wrote:

> 11 sep. 2022 kl. 13.28 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
>
> > This was a year ago, but it looks like none of these patches were
> > applied?
>
> Probably means they weren't very good to begin with.
>

Heh. That's a bit harsh, but also true more often than not.

>
> > I think having a sandbox mode would certainly be good in principle.
>
> Same here, but I know how perilous it is to design interfaces without a
> concrete and obviously useful application from the start so let's be
> careful.


I agree. Here's an obviously useful application in my humble opinion: to
turn on Elisp's Flymake checker by default.

To do that, we must ensure that this checker, which starts an emacs
inferior process to byte-compile Lisp code, is guaranteed not to cause
unintended side-effects.

This inferior Emacs macro-expands macro calls and thus and runs code:
there's no other way to compile Lisp code. It must thus not be allowed to
do "unsandboxy" things like writing to the file system or network. Probably
also not starting other processes. But probably it should be allowed to
cons lists and intern symbols inside its address space.

João

[Message part 2 (text/html, inline)]

Previous Next

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