From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Sandboxing (was: Safety of elisp-flymake-byte-compile) Date: Tue, 11 Dec 2018 14:30:43 -0500 Message-ID: References: <20181204233600.7907.75252@vcs0.savannah.gnu.org> <20181204233601.273DD209DC@vcs0.savannah.gnu.org> <87sgz89mpu.fsf_-_@gmail.com> <87mupe9qqw.fsf@gmail.com> <87in019dle.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1544556540 26094 195.159.176.226 (11 Dec 2018 19:29:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 19:29:00 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 20:28:56 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gWniB-0006dM-24 for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 20:28:55 +0100 Original-Received: from localhost ([::1]:41137 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWnkH-0007r8-OZ for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 14:31:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWnk8-0007r2-LM for emacs-devel@gnu.org; Tue, 11 Dec 2018 14:30:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWnk5-0006V5-Gr for emacs-devel@gnu.org; Tue, 11 Dec 2018 14:30:56 -0500 Original-Received: from [195.159.176.226] (port=53030 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gWnk5-0006UV-6s for emacs-devel@gnu.org; Tue, 11 Dec 2018 14:30:53 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gWnhv-0006K3-1C for emacs-devel@gnu.org; Tue, 11 Dec 2018 20:28:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 19 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:W7qFyg/2AiTVrTCId5+CvO/VHpE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231759 Archived-At: >> Providing ways to run Elisp in a confined environment would be useful in >> various circumstances, but it's non-trivial. > I can understand that, but I'm not proposing a fully hermetic sandbox > just something that ameliorates the problem. I think a first step might be to add a new boolean var `disallow-unsafe-effects` and then go through the C code to check this var whenever we do something "dangerous" (e.g. change a global var, launch a process, ...). I suspect that a boolean will be too coarse in the long run (we'll probably want to split this into different domains, maybe with some kind of capabilities, or maybe monitor the effect, or god knows what), but we need to start somewhere and this will at least let us annotate the code that is sensitive so it's easier afterwards to refine it. It will also let us see whether this affects performance-significant code. Stefan