GNU bug report logs - #45198
28.0.50; Sandbox mode

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Stefan Monnier <monnier@HIDDEN>; Keywords: patch; dated Sat, 12 Dec 2020 18:20:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 18:14:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 20 13:14:29 2020
Received: from localhost ([127.0.0.1]:45597 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kr3Dw-0007BO-Se
	for submit <at> debbugs.gnu.org; Sun, 20 Dec 2020 13:14:29 -0500
Received: from mail-oi1-f177.google.com ([209.85.167.177]:40068)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kr3Ds-0007B4-8F
 for 45198 <at> debbugs.gnu.org; Sun, 20 Dec 2020 13:14:27 -0500
Received: by mail-oi1-f177.google.com with SMTP id p126so9049042oif.7
 for <45198 <at> debbugs.gnu.org>; Sun, 20 Dec 2020 10:14:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=WhFyPfcNrbhH8CBCITWte9rnaVIkkzB/D2hJgUY6f/M=;
 b=FcDXCknAEP3CGDJEMLea+qj9R7vK7Ai4vkNzU/K5BrCOnNKz/zLGazRnD3NpzggH3I
 CaPhZ8Qlg9dkUXW85nxNzq0CGiElOTJna+J5cpUrKm9ldTBCWG4N/BjbZMdh942Bd/qg
 SVzp1YVfr/FHrYpI9i1ecbpuGJ21NH4zlnedvfxzzxZ5fH9IWvB+cgloXqndIsy0ELPI
 SKXG7c1W18y4h/QFIN8qES+pBHdfSvCV77tpH625bbRuDClNFPgJgEd6ljBxc/DFog6l
 NdCyIxz+lK725g4MFUcqRiX4crTZLpGaI/XASwzit/UCw878pVi4hAztaTEFCCqHUIM7
 HaPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=WhFyPfcNrbhH8CBCITWte9rnaVIkkzB/D2hJgUY6f/M=;
 b=nQv+mGpbDmpQ/WGOl4iC9q3u/S46VVkbTFx5b//TBD/ujNS1ohCTobAJqNZCWxGlcb
 l0SYAaHjhx3o6WnlvYNYnIloXR1kFfDbVBJNTQvzE64RlAOd24NjfmDPaDOEpxKs4gLy
 RiSE7v+J4PfZ6G0eWOmH3bQ91/2JUHCbMrw6SU5/SJ7ga0p23ieWpBCw/ljfN8EAMujC
 ITGFb5oAFLD126rHhW7z33laHztcZatkp6lZSPEtK22HeSqHOe96TqjD+dtVabR0R5WA
 /wlvaVyCT978sZr1Qwf0GK4dholeaL/v8wE21Mensfm28K/qlzLiBHoPUxqiUUWeoCia
 0w2g==
X-Gm-Message-State: AOAM530ELJCSbmoG8xpQnI3OKl+vdw4PY7I+trqcjpoNEuIbMDtgAS2M
 qQ2MUjtKz6LXx9/cnRVAoJHRYecnhoJ2SFFvpOo=
X-Google-Smtp-Source: ABdhPJyo8T23N+xIDfZFffMVTD0y7mx1utbbZYBznroquJ2rrg1qecqg+tQRTHBBis6RIF/uAwJWecZRMWq4emxG4i4=
X-Received: by 2002:a54:4881:: with SMTP id r1mr8865177oic.9.1608488058594;
 Sun, 20 Dec 2020 10:14:18 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
 <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
 <CAArVCkREr5S=k42mXhW8dMzAtmiv7AG8m5yTSFZ72Bey14=9tw@HIDDEN>
 <831rfktsxp.fsf@HIDDEN>
In-Reply-To: <831rfktsxp.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sun, 20 Dec 2020 19:14:07 +0100
Message-ID: <CAArVCkS3GfC-JwU=F_WHUon7KYfqdLRjG9dHxm_tVwJEOArKPQ@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Am So., 20. Dez. 2020 um 16:10 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
>
> > From: Philipp Stephani <p.stephani2@HIDDEN>
> > Date: Sat, 19 Dec 2020 23:22:08 +0100
> > Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
> >  Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
> >
> > diff --git a/configure.ac b/configure.ac
> > index 087dd67e18..cb698e34fe 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -4186,6 +4186,11 @@ AC_DEFUN
> >
> >  AC_CHECK_HEADERS([linux/seccomp.h])
> >
> > +LIBSECCOMP=3D
> > +AC_CHECK_HEADER([seccomp.h],
> > +  [AC_CHECK_LIB([seccomp], [seccomp_init], [LIBSECCOMP=3D-lseccomp])])
> > +AC_SUBST([LIBSECCOMP])
> > +
>
> Please also add this to the list in EMACS_CONFIG_FEATURES.

Hmm, this isn't really an Emacs feature, just an internal helper
binary, so I don't think it should be in any features list.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 15:10:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 20 10:10:30 2020
Received: from localhost ([127.0.0.1]:45352 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kr0Lr-0006tb-Lp
	for submit <at> debbugs.gnu.org; Sun, 20 Dec 2020 10:10:30 -0500
Received: from eggs.gnu.org ([209.51.188.92]:36258)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kr0Lm-0006tI-3V
 for 45198 <at> debbugs.gnu.org; Sun, 20 Dec 2020 10:10:26 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:47374)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kr0Lg-0003Lp-V9; Sun, 20 Dec 2020 10:10:16 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1528
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kr0Lf-0005oH-VL; Sun, 20 Dec 2020 10:10:16 -0500
Date: Sun, 20 Dec 2020 17:09:54 +0200
Message-Id: <831rfktsxp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <CAArVCkREr5S=k42mXhW8dMzAtmiv7AG8m5yTSFZ72Bey14=9tw@HIDDEN>
 (message from Philipp Stephani on Sat, 19 Dec 2020 23:22:08 +0100)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
 <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
 <CAArVCkREr5S=k42mXhW8dMzAtmiv7AG8m5yTSFZ72Bey14=9tw@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: bzg@HIDDEN, 45198 <at> debbugs.gnu.org, monnier@HIDDEN,
 joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Philipp Stephani <p.stephani2@HIDDEN>
> Date: Sat, 19 Dec 2020 23:22:08 +0100
> Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
>  João Távora <joaotavora@HIDDEN>
> 
> diff --git a/configure.ac b/configure.ac
> index 087dd67e18..cb698e34fe 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -4186,6 +4186,11 @@ AC_DEFUN
>  
>  AC_CHECK_HEADERS([linux/seccomp.h])
>  
> +LIBSECCOMP=
> +AC_CHECK_HEADER([seccomp.h],
> +  [AC_CHECK_LIB([seccomp], [seccomp_init], [LIBSECCOMP=-lseccomp])])
> +AC_SUBST([LIBSECCOMP])
> +

Please also add this to the list in EMACS_CONFIG_FEATURES.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 15:08:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 20 10:08:55 2020
Received: from localhost ([127.0.0.1]:45348 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kr0KN-0006qz-9q
	for submit <at> debbugs.gnu.org; Sun, 20 Dec 2020 10:08:55 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36009)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kr0KL-0006ql-KY
 for 45198 <at> debbugs.gnu.org; Sun, 20 Dec 2020 10:08:53 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 25F38100229;
 Sun, 20 Dec 2020 10:08:48 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A9F211000D1;
 Sun, 20 Dec 2020 10:08:46 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1608476926;
 bh=wyfx1meQKJRg3Uo37QrMmJeckESa+rp809i7Fhw1O8I=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=ZR00DdlQm9LNdP7h2KaEbxxuWmeszMu3RjqipwqQy7bt7OKm4mahMNoDPVNWqJpg6
 gQIJaXSueC7gtFNcwQnTg8AZNxwKMdTFno9LPT/sYBRm2cwD0PZlzJMu+J/A9Or01O
 UCmLXNvDgq7dj8rJu17O61R1WQDaN7rchAPh/e28QT0NhRTqdtw6oF9+8iGXuqbOcz
 TZFS7KK8kofUY7Z1asT2el/EHADzcqCc1MU7fr9WXoHJ0fPsr0ZkIJzQ3kiZsUGbWj
 IgAlAKaAhHtQa4iqSbNAAO+0vmB8zFe/ZGSu4HXjUX7rQp5vxdgLXCVSQKqiVEPMsI
 C8pzP8P5J8ZeA==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4ACED1203CA;
 Sun, 20 Dec 2020 10:08:46 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Mattias =?windows-1252?Q?Engdeg=E5rd?= <mattiase@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwv3600jzjn.fsf-monnier+emacs@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
 <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
 <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
 <jwvblepoeuq.fsf-monnier+emacs@HIDDEN>
 <239166D0-63F2-48CF-AC26-B306B99419BC@HIDDEN>
 <jwvblepv7ex.fsf-monnier+emacs@HIDDEN>
 <8623C27F-BDD9-4F6D-B365-51D0FEBCCDD2@HIDDEN>
 <jwva6u8lgoz.fsf-monnier+emacs@HIDDEN>
 <495A446B-9BC6-4B6D-BBA3-493A917E0E57@HIDDEN>
Date: Sun, 20 Dec 2020 10:08:45 -0500
In-Reply-To: <495A446B-9BC6-4B6D-BBA3-493A917E0E57@HIDDEN> ("Mattias
 =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Sun, 20 Dec 2020 15:12:01
 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.090 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Philipp Stephani <p.stephani2@HIDDEN>,
 =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>> It was suggested that no init files be loaded to make the Emacs subprocess
>>> start faster. (I'm neutral here.)
>> I still have no idea what this has to do with autoloads.
> If Emacs does not read the user's init file in the checking process, then
> autoloads for external packages are not defined and the byte-compiler will
> complain when encountering calls to functions defined in external packages
> not explicitly required. Other people seem to believe it's not a big deal;
> I'm unsure.

Oh, I think I see what you mean.  I suspect that "autoload" is not the
crux of the matter (and "init file" isn't either) and we'll only know
how important the issue is and how best to fix it with more experience.
E.g. maybe the better option will be for `elisp-flymake-byte-compile` to
try and pass down some of that contextual info
(e.g. `package-directory-list` and `load-path`) to the subprocess, or
maybe we'll want `elisp-flymake-byte-compile` to recognize the
`Package-Requires:` header, ...

I think the more important pressing issue will be to distinguish "config
file" (i.e. packages whose main purpose is to change the behavior of
Emacs when they're loaded) from "ELisp package file" (packages which,
according to the coding convention, should not change the behavior of
Emacs when loaded), since config files are likely to be full of false
positives that can't be conveniently fixed by the user whereas for
genuine ELisp package files we have a range of tools to fix
the warnings.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 14:12:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 20 09:12:08 2020
Received: from localhost ([127.0.0.1]:43934 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqzRQ-00057i-2O
	for submit <at> debbugs.gnu.org; Sun, 20 Dec 2020 09:12:08 -0500
Received: from mail205c50.megamailservers.eu ([91.136.10.215]:34134
 helo=mail193c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1kqzRN-00057Z-T9
 for 45198 <at> debbugs.gnu.org; Sun, 20 Dec 2020 09:12:06 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1608473524;
 bh=hKY/qNSrnij/YMBTgespLFqAIVidpainOX1kzDFbXCI=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=hQRmhygTx0RfU2hJUdN80sgaY6gPl9j6eAwdvM+9ZatsTVYs1+W/AWAvlK4QYh0c1
 9F/KGrxzWVbOXv81RCWjANa5fkIhEDHSHIySHqw80K+zDiOm7PZCj/roQpKVc7vzTW
 bCXypM9L/3+Z4KtqQUxRJmVvyRktFJFcxf1bsyTU=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-064ae655.032-75-73746f71.bbcust.telenor.se
 [85.230.74.6]) (authenticated bits=0)
 by mail193c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BKEC1PE021032; 
 Sun, 20 Dec 2020 14:12:03 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <jwva6u8lgoz.fsf-monnier+emacs@HIDDEN>
Date: Sun, 20 Dec 2020 15:12:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <495A446B-9BC6-4B6D-BBA3-493A917E0E57@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
 <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
 <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
 <jwvblepoeuq.fsf-monnier+emacs@HIDDEN>
 <239166D0-63F2-48CF-AC26-B306B99419BC@HIDDEN>
 <jwvblepv7ex.fsf-monnier+emacs@HIDDEN>
 <8623C27F-BDD9-4F6D-B365-51D0FEBCCDD2@HIDDEN>
 <jwva6u8lgoz.fsf-monnier+emacs@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A782F17.5FDF5BB4.0022, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=TYHoSiYh c=1 sm=1 tr=0 a=Ni+dBsiEfW2GqKMPYZim9A==:117
 a=Ni+dBsiEfW2GqKMPYZim9A==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=iRZporoAAAAA:8 a=bxs3z4yZ_2YFj9mWbJwA:9 a=CjuIK1q_8ugA:10
 a=NOBgFS-JBQ2l-kSd6-zu:22
X-Origin-Country: SE
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Philipp Stephani <p.stephani2@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

20 dec. 2020 kl. 15.02 skrev Stefan Monnier <monnier@HIDDEN>:
>=20
>> It was suggested that no init files be loaded to make the Emacs =
subprocess
>> start faster. (I'm neutral here.)
>=20
> I still have no idea what this has to do with autoloads.

If Emacs does not read the user's init file in the checking process, =
then autoloads for external packages are not defined and the =
byte-compiler will complain when encountering calls to functions defined =
in external packages not explicitly required. Other people seem to =
believe it's not a big deal; I'm unsure.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 14:02:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 20 09:02:34 2020
Received: from localhost ([127.0.0.1]:43910 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqzIA-0004tC-EH
	for submit <at> debbugs.gnu.org; Sun, 20 Dec 2020 09:02:34 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42044)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kqzI8-0004sz-IZ
 for 45198 <at> debbugs.gnu.org; Sun, 20 Dec 2020 09:02:32 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3DFE6440334;
 Sun, 20 Dec 2020 09:02:27 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 236F2440099;
 Sun, 20 Dec 2020 09:02:26 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1608472946;
 bh=tjP5ZY8W7/QbIj/jhSekLcpYN8HcXmW5T/QikeGxO9Y=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=WEGpjBkY4bARaZSd6vPDQT93ybMGT72e3WBdm/tTwDFFhc0yhSru+Uo5ltIVIXwL7
 /mLP1USv+ASkZfl1mE4D9sJjivv/fkMSSiu6d0Jh4rDeC0+g+xhxuws16Xj63xe4J6
 Ux6ioiihSHkiZJix9wEIFKI2nrxSleDxbQBxaAO2DGhxozAtgW9pdiErBnQ7cVVBr2
 NnpGJvaCxIW2gRN+LCV0dIC9hJRoEfvA+Mku6ESySWXd2OE3V5BkH7xmukEWhXRrsq
 oTF3WezqtqWkQLtf2OzUc9j22x6S2RQaU+XTu9+/u9rS83ajTVPQSRhpm+fhwUoQWy
 d13ZBe2iDb9FA==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D2BF3120183;
 Sun, 20 Dec 2020 09:02:25 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Mattias =?windows-1252?Q?Engdeg=E5rd?= <mattiase@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwva6u8lgoz.fsf-monnier+emacs@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
 <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
 <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
 <jwvblepoeuq.fsf-monnier+emacs@HIDDEN>
 <239166D0-63F2-48CF-AC26-B306B99419BC@HIDDEN>
 <jwvblepv7ex.fsf-monnier+emacs@HIDDEN>
 <8623C27F-BDD9-4F6D-B365-51D0FEBCCDD2@HIDDEN>
Date: Sun, 20 Dec 2020 09:02:24 -0500
In-Reply-To: <8623C27F-BDD9-4F6D-B365-51D0FEBCCDD2@HIDDEN> ("Mattias
 =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Sun, 20 Dec 2020 14:15:36
 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.071 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Philipp Stephani <p.stephani2@HIDDEN>,
 =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I don't understand why it would be different for autoloads than for
>> functions provided by `require`d packages.
> It was suggested that no init files be loaded to make the Emacs subprocess
> start faster. (I'm neutral here.)

I still have no idea what this has to do with autoloads.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 13:15:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 20 08:15:47 2020
Received: from localhost ([127.0.0.1]:43869 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqyYt-0003mK-2D
	for submit <at> debbugs.gnu.org; Sun, 20 Dec 2020 08:15:47 -0500
Received: from mail70c50.megamailservers.eu ([91.136.10.80]:44110)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1kqyYn-0003m5-Pv
 for 45198 <at> debbugs.gnu.org; Sun, 20 Dec 2020 08:15:45 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1608470140;
 bh=l4hUXCxqwaNBHaeh8zQx09euAyExAJnO342hU7IBRYA=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=QOOdO0SY1PZG0YsIsW2xdxfcUdSKIYtia5AMGqMIYXUMJi/STnlOMMU/jr+Lw3SHB
 JAyDjNCIZTojUuQI1DUqvIjboVYLzs9sfM5pco3OR5eJ6GMVZjgTzZri9jecJLSV3R
 wqlnzwqgDg7Nitzop63H2OPJMPQJtGGi8tnhxHcw=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-064ae655.032-75-73746f71.bbcust.telenor.se
 [85.230.74.6]) (authenticated bits=0)
 by mail70c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BKDFaFJ028422; 
 Sun, 20 Dec 2020 13:15:38 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <jwvblepv7ex.fsf-monnier+emacs@HIDDEN>
Date: Sun, 20 Dec 2020 14:15:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8623C27F-BDD9-4F6D-B365-51D0FEBCCDD2@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
 <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
 <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
 <jwvblepoeuq.fsf-monnier+emacs@HIDDEN>
 <239166D0-63F2-48CF-AC26-B306B99419BC@HIDDEN>
 <jwvblepv7ex.fsf-monnier+emacs@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A782F18.5FDF4E7C.001D, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=UIOj4xXy c=1 sm=1 tr=0 a=Ni+dBsiEfW2GqKMPYZim9A==:117
 a=Ni+dBsiEfW2GqKMPYZim9A==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=iRZporoAAAAA:8 a=IvpEyDUsbBtNW09VDtsA:9 a=CjuIK1q_8ugA:10
 a=NOBgFS-JBQ2l-kSd6-zu:22
X-Origin-Country: SE
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Philipp Stephani <p.stephani2@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

19 dec. 2020 kl. 22.01 skrev Stefan Monnier <monnier@HIDDEN>:

> I don't understand why it would be different for autoloads than for
> functions provided by `require`d packages.

It was suggested that no init files be loaded to make the Emacs =
subprocess start faster. (I'm neutral here.)

> Also, if we add all the dirs in `load-path` to the set of readable
> directories (and I do think we want to do that) this should not be
> an issue, right?

Certainly, as long as we run the code defining the autoloads to begin =
with.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 12:29:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 20 07:29:10 2020
Received: from localhost ([127.0.0.1]:43834 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqxpm-0000Yi-Dg
	for submit <at> debbugs.gnu.org; Sun, 20 Dec 2020 07:29:10 -0500
Received: from mail-ot1-f44.google.com ([209.85.210.44]:34062)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kqxpl-0000YW-7g
 for 45198 <at> debbugs.gnu.org; Sun, 20 Dec 2020 07:29:09 -0500
Received: by mail-ot1-f44.google.com with SMTP id a109so6448512otc.1
 for <45198 <at> debbugs.gnu.org>; Sun, 20 Dec 2020 04:29:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=dWCwr+RiqpIDBg+4pc0m+Ui9BA5xHZrEqyrPzsFi9F0=;
 b=aDuxEzjPEOOGXNBmFchnrShY2wC/U0nMlADJPHCcCrsqFBHg3nlpCXNxfFM/tjDx4y
 83VopibGX3hIvuTvyxx7XFTY3DAyJq57zB4aPpwBEmN/m0mTeJGqI7uMXu7Bzi/Cb4Om
 0lrlQijMmXKi5dXBlol0YNJZaDMvpZZe31wmkkWP8cardd9+lHQ0011OvJb8003FAMfI
 rfbIK5PTHrVZ1UORHkOnKly4ApwbZBmGR0xj9EcvPpg1t9SuJPO02mPuffMiVoQJWMPW
 xWSaD9PNC0UYKu8LZGRNaV3UPQRqGW+1S/xmgMp6xQvjjncwLijurxf1OYIvTg8wJVIo
 j3Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=dWCwr+RiqpIDBg+4pc0m+Ui9BA5xHZrEqyrPzsFi9F0=;
 b=eamO9yVOJ99XkeTuwHlxH+kqwZguWx4wvGqvNtatRJ3XIDpsT4RI9mv5lb8eU/vEx+
 6dY0Sh5n9ofRSi2rAAOTJBBddhj5Sd5KErUbc0k08Lw5ryi4QXxvIIfs9GIgeleT9Aso
 Np4BcFwGMKmGCg83olHHGJ96jnWjjEqGqaLygkoKDmjNPTfs9q2klPLyPMVFwvtWDq8n
 NGRPZEB+JfY5D+Wixzqnb1Vgk0tl9SJQ8DZ0JrIw6uY2EiLq1g0nUDCTsOz0ll4WgWnO
 Fu0/YnJeOYQNpXy+CfhvLWZfSRSK6K/diPU5fAGRDqusTQYw9F3Nxz+X9DdVkid3uKaq
 8udw==
X-Gm-Message-State: AOAM530Kh6wdzw6K/HsWgZ60/HX6le0rqUIfjNo26VGG2NohJ6xdtkzF
 n0u/qH9GLNMytZjUFHjgWp1K664zVIJP7s2an6Q=
X-Google-Smtp-Source: ABdhPJx63kppc+vGSJP7aqFhrrShrODbyIShcArRhP0hwI+7CBDlqriHsUMcuj++gSLndAQu6rfY3cTu8qYthV9SRo8=
X-Received: by 2002:a9d:72c4:: with SMTP id d4mr8996250otk.149.1608467343244; 
 Sun, 20 Dec 2020 04:29:03 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
 <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
 <jwv4kkoiim5.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSZ_DJ-i3h6owOedgYj6eB60YedX3eo5wP3kr_Bhy8Spw@HIDDEN>
 <jwvczz5mlr6.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvczz5mlr6.fsf-monnier+emacs@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sun, 20 Dec 2020 13:28:51 +0100
Message-ID: <CAArVCkTLyGNXyaC2QAoU4TM9+VxeWPEG5gOWLCGzbHC9cR+udg@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Am So., 20. Dez. 2020 um 00:17 Uhr schrieb Stefan Monnier
<monnier@HIDDEN>:
>
> >> I think "the right thing" would be to represent the parent as a process
> >> object inside the child.  I proposed dedicated functions only because
> >> but when it uses stdin/stdout, providing a process object seems awkward
> >> to implement.
> > What would be the difference? It would be a pipe process wrapping some
> > open file descriptor pair in both cases.
>
> Differences:
>
> 1- we don't have this pipe process wrapping of stdin/stdout so it's extra
>    C code we currently don't have.

But we also don't have pipe processes wrapping file descriptors passed
on the command line, or pipes that aren't close-on-exec, so core
changes are needed in any case.

> 2- I suspect that it wouldn't be quite so easy because it may interfere
>    with other preexisting uses of stdin/stdout in the C code.

Yes, the read end of the pipe would have to deal with interleaved
output from process-send-string and print.

>
> If/when someone implements that, then indeed we can just use a process
> object to represent the parent in the client as well.
>

Yes, but again, there's no difference between the standard streams and
using newly-allocated file descriptors. In both cases, you need a
variant of Fmake_pipe_process that doesn't call pipe2 twice, but wraps
two existing file descriptors in its infd and outfd. Whether those
happen to be 0 and 1 or something passed on the command line makes no
difference.
On the parent process side, if you want to use a separate pipe pair,
you need a way to create a pipe process that doesn't use O_CLOEXEC and
allows reading out the open file descriptors to be able to pass them
to the subprocess on the command line.
These changes aren't large, but they are necessary if you want to go
the "extra pipe pair" route.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 23:17:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 18:17:10 2020
Received: from localhost ([127.0.0.1]:43418 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqlTK-00020D-5h
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 18:17:10 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48160)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kqlTG-0001ze-49
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 18:17:09 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 96483100222;
 Sat, 19 Dec 2020 18:17:00 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 39273100068;
 Sat, 19 Dec 2020 18:16:59 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1608419819;
 bh=AH7bywzwbyb9BbkK+wxTbj8m1WSJh8UkUqV0RJfrwo8=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=Co7DBH9wjzDQRVM8gdL8nG94O2BTSQFFBMbgSK44tEOC93kjdNRjaA2CPS9Ze3l4G
 ebKum9kUbdIHAElHCUl/Fd83t5c7GkgMZpomXqwVt6/rsWXBCtQGgkDxWFGl8Vcpei
 O0fpKXz1otmzTroFEZSChyEHfqa2GzRIeBkiG5XATYuZKrkciYzJLxsEW2YxBDi7u6
 W9UGCWV/ko3XNSFQ1Paq5uvRP1KogeuiivfmlSMFf7wlTSgM8b9gDFDZRE3LtHv6e/
 /inlfOENkxDa0iB/ABTf6ukx2mMOQJu7BPdWAEoIWHtMHe6otN0Uvytt4LSwXJ2lvh
 rKMhlg+ytPXRg==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EA77412017E;
 Sat, 19 Dec 2020 18:16:58 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwvczz5mlr6.fsf-monnier+emacs@HIDDEN>
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
 <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
 <jwv4kkoiim5.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSZ_DJ-i3h6owOedgYj6eB60YedX3eo5wP3kr_Bhy8Spw@HIDDEN>
Date: Sat, 19 Dec 2020 18:16:58 -0500
In-Reply-To: <CAArVCkSZ_DJ-i3h6owOedgYj6eB60YedX3eo5wP3kr_Bhy8Spw@HIDDEN>
 (Philipp Stephani's message of "Sat, 19 Dec 2020 23:41:50 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.088 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?windows-1252?B?Sm/j?= =?windows-1252?B?byBU4XZvcmE=?=
 <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I think "the right thing" would be to represent the parent as a process
>> object inside the child.  I proposed dedicated functions only because
>> but when it uses stdin/stdout, providing a process object seems awkward
>> to implement.
> What would be the difference? It would be a pipe process wrapping some
> open file descriptor pair in both cases.

Differences:

1- we don't have this pipe process wrapping of stdin/stdout so it's extra
   C code we currently don't have.
2- I suspect that it wouldn't be quite so easy because it may interfere
   with other preexisting uses of stdin/stdout in the C code.

If/when someone implements that, then indeed we can just use a process
object to represent the parent in the client as well.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 22:42:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 17:42:10 2020
Received: from localhost ([127.0.0.1]:43359 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqkvS-00017o-Jg
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 17:42:10 -0500
Received: from mail-ot1-f49.google.com ([209.85.210.49]:37029)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kqkvQ-00017a-0K
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 17:42:09 -0500
Received: by mail-ot1-f49.google.com with SMTP id o11so5545567ote.4
 for <45198 <at> debbugs.gnu.org>; Sat, 19 Dec 2020 14:42:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=XkYQxjS7reYmU7UX4w0kZv06hGOgTS9ZR7NgErIslfU=;
 b=N53f9wcHYmdpztu7EvVGwm+VilWbYkLGbChjLoJ4T+itXkUzCDyZwL6XdlLXPWV742
 4NpCC7xTCSAO8jjY3VaZD+j5kaFs5sqa2A/xjZ/vqs//28Lxn5xBgWRVmixjoZZYjnyD
 D/U91Db1JZsn5bEpAvjfsyHxNIHcZoXDZRPl1wPYo7nrv2NYgYMLnALGagm9vPChUUo/
 k71uMhjbiY+W4/6edYodybCx9c6y1pqNEmdKjv3+HkVlPoQGrwyZAcPXRwpvQ35fS8eO
 N0uGkB7V+AKS7Sy8N+BmsJQsZzFPlAJYPiVV6d2nsl66asY8NicPWfhVGE/j73t0ABGN
 cjTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=XkYQxjS7reYmU7UX4w0kZv06hGOgTS9ZR7NgErIslfU=;
 b=NStGBwZSxdGavRqnh9hQUFB6KSS2tOJsYfOrZ43gVFqEC1eTbQ7WI0yFGJQzwMhENH
 0NgY56+5LIa1Gt52epsyRH3zcjoaGlBVAtFyfFEuoXVzTseeVOF20Pq+Tal9gczSHq/2
 Dj5vFEfYFXotpuydI8mqGZWoytxZqYs9AxQukC843m6hKzAuYZ0LkivUDNmmziVRf/fT
 mCexI7rBQrj2xx7nKolbTXBMe66T1hJMaPaG7yQ0tRcaGiYupHpI6kc+kk+rkZz4O+nJ
 rg8ZfMfT8YKU1JqkP7IkpWv3ma4D6up5mSz9A4V639hdmOCsUnITLz9JZAuOaN3fsYXI
 5slA==
X-Gm-Message-State: AOAM532vnVJ8i0ezVQZlN58TwW/lpyNqIylgzktU6me7vqdsP8Q6ivC8
 c2CZUlIG7SZEu5dLb+oRtvh151jBsSbbMiPgIcc=
X-Google-Smtp-Source: ABdhPJzt88T0TIS5w+xePStBghxRLYhL3I908pBEFblLab8nYu0KPX/RbTkjGf9hDwsTdq0CQARjm1d2vkKcNReSeUw=
X-Received: by 2002:a9d:269:: with SMTP id 96mr7282858otb.174.1608417722174;
 Sat, 19 Dec 2020 14:42:02 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
 <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
 <jwv4kkoiim5.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwv4kkoiim5.fsf-monnier+emacs@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 19 Dec 2020 23:41:50 +0100
Message-ID: <CAArVCkSZ_DJ-i3h6owOedgYj6eB60YedX3eo5wP3kr_Bhy8Spw@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Am Mo., 14. Dez. 2020 um 15:44 Uhr schrieb Stefan Monnier
<monnier@HIDDEN>:
> >>     Returns a process object.
> > Depending how much we care about forward compatibility, it might be
> > better to return an opaque sandbox object (which will initially wrap a
> > process object).
>
> We always use process objects to represent file-descriptors, so I can't
> find any good reason why this one should be different or why an
> implementation might find it difficult to expose a process object.

If we return a single pipe process object here, then there would be no
way to access or wait for the actual Emacs process object. That might
be OK, but maybe it's not. Does Emacs guarantee that (while
(accept-process-output PIPE)) for some pipe process reads the entire
process output and finishes in due time (not too long after the actual
process)? Also, how would we report errors from the subprocess? A pipe
process can't really fail, right?

>
> >>     FUNCTION is called with no arguments and it can use `sandbox-read`
> >>     to read the data sent to the process object via `process-send-string`,
> >>     and `sandbox-reply` to send back a reply to the parent process
> >>     (which will receive it via its `process-filter`).
> > That is, sandbox-read and sandbox-reply just read/write stdin/stdout?
>
> While it may use stdin/stdout internally, I can imagine good reasons why
> we'd want to use some other file descriptors.

Yes, it should in many cases not be stdin/stdout. The standard output
and error are polluted with log messages, and stdin should likely be
closed or empty to avoid Emacs trying to read from it.
It should definitely be possible to create a "magic" pipe process
(similar to the "magic network process" created for systemd socket
activation) that wraps a file descriptor pair passed on the
command-line.
OTOH, for the case at hand using stdout/stderr seems right: the error
messages are printed there, and the parent Emacs process can parse
them.
Or do you suggest sending the error messages in a structured format
(e.g. JSON) over the pipe?

>
> > That would certainly work, but (a) it doesn't really have anything to
> > do with sandboxing, so these functions should rather be called
> > stdin-read and stdout-write or similar,
>
> I think "the right thing" would be to represent the parent as a process
> object inside the child.  I proposed dedicated functions only because
> but when it uses stdin/stdout, providing a process object seems awkward
> to implement.

What would be the difference? It would be a pipe process wrapping some
open file descriptor pair in both cases.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 22:22:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 17:22:30 2020
Received: from localhost ([127.0.0.1]:43347 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqkcP-0000f7-Tp
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 17:22:30 -0500
Received: from mail-oi1-f178.google.com ([209.85.167.178]:45776)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kqkcL-0000ep-Fu
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 17:22:28 -0500
Received: by mail-oi1-f178.google.com with SMTP id f132so7149805oib.12
 for <45198 <at> debbugs.gnu.org>; Sat, 19 Dec 2020 14:22:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=7FK+JaXW1OyrONduSYQ5jzTOnCY5M6FYqcUMVtM96tY=;
 b=YFbGtd5yQZ09tm4pTAqh29QRZTHOtGWM8mInlKbivnBJzoIVLzo1a6V5fQgUj5Ndva
 sZZHUN3vyfTbEXZ+odD7//c1mewYz7MV478hvPZ095nJyesck4Oo+uC42dH5lEQKBmIX
 kH4KrAk0FhXK+ZjAKHzmbqsNYfsq3oHIzcnPTvI2ivx2GiFtBhlOigEcsyeYbWqT90mq
 UZRAG5q+lPTaTXApzuS9Sly3+b+CHFa9lN50EJa79tJhRlDT/cMwJxHNdh5JVmEQHrGZ
 EWZONeysgcAIzFdnBVVfwCr0bNom0yoAcImgrL5+Qfg+Of8uXQjCT5aXUz1LWnhY1esI
 b4Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=7FK+JaXW1OyrONduSYQ5jzTOnCY5M6FYqcUMVtM96tY=;
 b=gYQsPHgn4P/P3/GYxSqOJr5qYwoJMrn62zl+PYDRZMh52Eq0dz0SUsvjNTusafPA6l
 eMeW6SULtCQ40tXlyzdpipCG4Rh+tUMiY8X0QrcH1b/iEvheRlHzKgQdtIw64vfawSHA
 A2m0f9GLNvmY/7+Jps5F/1BkkXEmojYC+d4polZ5QtyUvVcxskx6Y93Dr7YtBDaXgy+b
 eX6MJwAWjny2sDKzEtLSXEyi49nFu0EJvAa882jOYgmJcR9O3snCZjtuolxeLX5w+zot
 juf/SKnIfoUuOQVOadjJ4sxI6daTHX9VTaVcVNho6d/7Z6SeI65K2NjYCZE08Mib0HCk
 9Zvw==
X-Gm-Message-State: AOAM533dYYPa4MOdXa03nEs+T0wL2+afN803Q9TK53mUGbl4F/r2XwB4
 i0dK6nzxQQQVEQK/FkQ/AKpG40PDXAHyUaTy9Bk=
X-Google-Smtp-Source: ABdhPJyKSjy2gd7riw9JqRHetIuWcnhXJSHEpufMQ0fte8LA4gNAgiXcgBzDJzhFUd8qakHC1Q3hvAttYajklpeLQp0=
X-Received: by 2002:aca:3a02:: with SMTP id h2mr6734079oia.65.1608416539743;
 Sat, 19 Dec 2020 14:22:19 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
 <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
In-Reply-To: <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 19 Dec 2020 23:22:08 +0100
Message-ID: <CAArVCkREr5S=k42mXhW8dMzAtmiv7AG8m5yTSFZ72Bey14=9tw@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/mixed; boundary="00000000000080b8ad05b6d8a897"
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

--00000000000080b8ad05b6d8a897
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Am Mo., 14. Dez. 2020 um 12:05 Uhr schrieb Philipp Stephani
<p.stephani2@HIDDEN>:

> > >> - This will need someone else doing the implementation.
> > > Looks like we already have a volunteer for macOS.
> > > For Linux, this shouldn't be that difficult either. The sandbox needs
> > > to install a mount namespace that only allows read access to Emacs's
> > > installation directory plus any input file and write access to known
> > > output files, and enable syscall filters that forbid everything excep=
t
> > > a list of known-safe syscalls (especially exec). I can take a stab at
> > > that, but I can't promise anything ;-)
> >
> > Looking forward to it.
> >
>
> I've looked into this, and what I'd suggest for now is:
> [=E2=80=A6]
> 2. Generate appropriate seccomp filters using libseccomp or similar.

Here's a patch for this step.

--00000000000080b8ad05b6d8a897
Content-Type: text/x-patch; charset="US-ASCII"; 
	name="0002-Add-a-helper-binary-to-create-a-basic-Secure-Computi.patch"
Content-Disposition: attachment; 
	filename="0002-Add-a-helper-binary-to-create-a-basic-Secure-Computi.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_kiw9o4ra0>
X-Attachment-Id: f_kiw9o4ra0

RnJvbSBmNWQyMThlZjM1NGVjMjFkODU2NjI3MTU3MDk0OGQ3YzZiNzc2NjQ5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh
dGU6IFRodSwgMTcgRGVjIDIwMjAgMTE6MjA6NTUgKzAxMDAKU3ViamVjdDogW1BBVENIIDIvMl0g
QWRkIGEgaGVscGVyIGJpbmFyeSB0byBjcmVhdGUgYSBiYXNpYyBTZWN1cmUgQ29tcHV0aW5nCiBm
aWx0ZXIuCgpUaGUgYmluYXJ5IHVzZXMgdGhlICdzZWNjb21wJyBoZWxwZXIgbGlicmFyeS4gIFRo
ZSBsaWJyYXJ5IGlzbid0Cm5lZWRlZCB0byBsb2FkIHRoZSBnZW5lcmF0ZWQgU2VjdXJlIENvbXB1
dGluZyBmaWx0ZXIuCgoqIGNvbmZpZ3VyZS5hYzogQ2hlY2sgZm9yICdzZWNjb21wJyBoZWFkZXIg
YW5kIGxpYnJhcnkuCgoqIGxpYi1zcmMvc2VjY29tcC1maWx0ZXIuYzogTmV3IGhlbHBlciBiaW5h
cnkgdG8gZ2VuZXJhdGUgYSBnZW5lcmljClNlY3VyZSBDb21wdXRpbmcgZmlsdGVyIGZvciBHTlUv
TGludXguCgoqIGxpYi1zcmMvTWFrZWZpbGUuaW4gKERPTlRfSU5TVEFMTCk6IEFkZCAnc2VjY29t
cC1maWx0ZXInIGhlbHBlcgpiaW5hcnkgaWYgcG9zc2libGUuCihhbGwpOiBBZGQgU2VjdXJlIENv
bXB1dGluZyBmaWx0ZXIgZmlsZSBpZiBwb3NzaWJsZS4KKHNlY2NvbXAtZmlsdGVyJChFWEVFWFQp
KTogQ29tcGlsZSBoZWxwZXIgYmluYXJ5Lgooc2VjY29tcC1maWx0ZXIuYnBmIHNlY2NvbXAtZmls
dGVyLnBmYyk6IEdlbmVyYXRlIGZpbHRlciBmaWxlcy4KCiogdGVzdC9zcmMvZW1hY3MtdGVzdHMu
ZWwgKGVtYWNzLXRlc3RzL3NlY2NvbXAvYWxsb3dzLXN0ZG91dCkKKGVtYWNzLXRlc3RzL3NlY2Nv
bXAvZm9yYmlkcy1zdWJwcm9jZXNzKTogTmV3IHVuaXQgdGVzdHMuCgoqIHRlc3QvTWFrZWZpbGUu
aW4gKHNyYy9lbWFjcy10ZXN0cy5sb2cpOiBBZGQgZGVwZW5kZW5jeSBvbiB0aGUgaGVscGVyCmJp
bmFyeS4KLS0tCiAuZ2l0aWdub3JlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICA1ICsKIGNvbmZpZ3VyZS5hYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDUg
KwogbGliLXNyYy9NYWtlZmlsZS5pbiAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxOSArKwog
bGliLXNyYy9zZWNjb21wLWZpbHRlci5jICAgICAgICAgICAgICAgICAgICB8IDMwMyArKysrKysr
KysrKysrKysrKysrKwogdGVzdC9NYWtlZmlsZS5pbiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgMiArCiB0ZXN0L3NyYy9lbWFjcy1yZXNvdXJjZXMvc2VjY29tcC1maWx0ZXIuYnBmIHwg
ICAxICsKIHRlc3Qvc3JjL2VtYWNzLXRlc3RzLmVsICAgICAgICAgICAgICAgICAgICAgfCAgNDQg
KysrCiA3IGZpbGVzIGNoYW5nZWQsIDM3OSBpbnNlcnRpb25zKCspCiBjcmVhdGUgbW9kZSAxMDA2
NDQgbGliLXNyYy9zZWNjb21wLWZpbHRlci5jCiBjcmVhdGUgbW9kZSAxMjAwMDAgdGVzdC9zcmMv
ZW1hY3MtcmVzb3VyY2VzL3NlY2NvbXAtZmlsdGVyLmJwZgoKZGlmZiAtLWdpdCBhLy5naXRpZ25v
cmUgYi8uZ2l0aWdub3JlCmluZGV4IGJmN2U5MzQ5ODEuLjhjOGIxZjc1ODQgMTAwNjQ0Ci0tLSBh
Ly5naXRpZ25vcmUKKysrIGIvLmdpdGlnbm9yZQpAQCAtMTg3LDYgKzE4Nyw3IEBAIGxpYi1zcmMv
bWFrZS1kb2NmaWxlCiBsaWItc3JjL21ha2UtZmluZ2VycHJpbnQKIGxpYi1zcmMvbW92ZW1haWwK
IGxpYi1zcmMvcHJvZmlsZQorbGliLXNyYy9zZWNjb21wLWZpbHRlcgogbGliLXNyYy90ZXN0LWRp
c3RyaWIKIGxpYi1zcmMvdXBkYXRlLWdhbWUtc2NvcmUKIG5leHRzdGVwL0NvY29hL0VtYWNzLmJh
c2UvQ29udGVudHMvSW5mby5wbGlzdApAQCAtMjk4LDMgKzI5OSw3IEBAIG50L2VtYWNzLnJjCiBu
dC9lbWFjc2NsaWVudC5yYwogc3JjL2dkYi5pbmkKIC92YXIvCisKKyMgU2VjY29tcCBmaWx0ZXIg
ZmlsZXMuCitsaWItc3JjL3NlY2NvbXAtZmlsdGVyLmJwZgorbGliLXNyYy9zZWNjb21wLWZpbHRl
ci5wZmMKZGlmZiAtLWdpdCBhL2NvbmZpZ3VyZS5hYyBiL2NvbmZpZ3VyZS5hYwppbmRleCAwODdk
ZDY3ZTE4Li5jYjY5OGUzNGZlIDEwMDY0NAotLS0gYS9jb25maWd1cmUuYWMKKysrIGIvY29uZmln
dXJlLmFjCkBAIC00MTg2LDYgKzQxODYsMTEgQEAgQUNfREVGVU4KIAogQUNfQ0hFQ0tfSEVBREVS
UyhbbGludXgvc2VjY29tcC5oXSkKIAorTElCU0VDQ09NUD0KK0FDX0NIRUNLX0hFQURFUihbc2Vj
Y29tcC5oXSwKKyAgW0FDX0NIRUNLX0xJQihbc2VjY29tcF0sIFtzZWNjb21wX2luaXRdLCBbTElC
U0VDQ09NUD0tbHNlY2NvbXBdKV0pCitBQ19TVUJTVChbTElCU0VDQ09NUF0pCisKIE9MRF9MSUJT
PSRMSUJTCiBMSUJTPSIkTElCX1BUSFJFQUQgJExJQl9NQVRIICRMSUJTIgogQUNfQ0hFQ0tfRlVO
Q1MoYWNjZXB0NCBmY2hkaXIgZ2V0aG9zdG5hbWUgXApkaWZmIC0tZ2l0IGEvbGliLXNyYy9NYWtl
ZmlsZS5pbiBiL2xpYi1zcmMvTWFrZWZpbGUuaW4KaW5kZXggYTJkMjdlYWIwMC4uNzJhOTgwZTRk
ZSAxMDA2NDQKLS0tIGEvbGliLXNyYy9NYWtlZmlsZS5pbgorKysgYi9saWItc3JjL01ha2VmaWxl
LmluCkBAIC0yMDksNiArMjA5LDEyIEBAIExJQl9FQUNDRVNTPQogIyMgZW1wdHkgb3IgLWx3c29j
azIgZm9yIE1pbkdXCiBMSUJfV1NPQ0szMj1ATElCX1dTT0NLMzJACiAKK0xJQlNFQ0NPTVA9QExJ
QlNFQ0NPTVBACisKK2lmbmVxICgkKExJQlNFQ0NPTVApLCkKK0RPTlRfSU5TVEFMTCArPSBzZWNj
b21wLWZpbHRlciQoRVhFRVhUKQorZW5kaWYKKwogIyMgRXh0cmEgbGlicmFyaWVzIHRvIHVzZSB3
aGVuIGxpbmtpbmcgbW92ZW1haWwuCiBMSUJTX01PVkUgPSAkKExJQlNfTUFJTCkgJChLUkI0TElC
KSAkKERFU0xJQikgJChLUkI1TElCKSAkKENSWVBUT0xJQikgXAogICAgICAgICAgICAgJChDT01f
RVJSTElCKSAkKExJQkhFU0lPRCkgJChMSUJSRVNPTFYpICQoTElCX1dTT0NLMzIpCkBAIC0yMzgs
NiArMjQ0LDEwIEBAIGNvbmZpZ19oID0KIAogYWxsOiAke0VYRV9GSUxFU30gJHtTQ1JJUFRTfQog
CitpZm5lcSAoJChMSUJTRUNDT01QKSwpCithbGw6IHNlY2NvbXAtZmlsdGVyLmJwZgorZW5kaWYK
KwogLlBIT05ZOiBhbGwgbmVlZC1ibGVzc21haWwgbWF5YmUtYmxlc3NtYWlsCiAKIExPQURMSUJF
UyA9IC4uL2xpYi9saWJnbnUuYSAkKExJQlNfU1lTVEVNKQpAQCAtNDIwLDQgKzQzMCwxMyBAQCB1
cGRhdGUtZ2FtZS1zY29yZSR7RVhFRVhUfToKIGVtYWNzY2xpZW50LnJlczogLi4vbnQvZW1hY3Nj
bGllbnQucmMgJChOVElOQykvLi4vaWNvbnMvZW1hY3MuaWNvCiAJJChBTV9WX1JDKSQoV0lORFJF
UykgLU8gY29mZiAtLWluY2x1ZGUtZGlyPSQoTlRJTkMpLy4uIC1vICRAICQ8CiAKK2lmbmVxICgk
KExJQlNFQ0NPTVApLCkKK3NlY2NvbXAtZmlsdGVyJChFWEVFWFQpOiAkKHNyY2Rpcikvc2VjY29t
cC1maWx0ZXIuYyAkKGNvbmZpZ19oKQorCSQoQU1fVl9DQ0xEKSQoQ0MpICQoQUxMX0NGTEFHUykg
JDwgJChMSUJTRUNDT01QKSAtbyAkQAorCitzZWNjb21wLWZpbHRlci5icGYgc2VjY29tcC1maWx0
ZXIucGZjOiBzZWNjb21wLWZpbHRlciQoRVhFRVhUKQorCSQoQU1fVl9HRU4pLi9zZWNjb21wLWZp
bHRlciQoRVhFRVhUKSBcCisJICBzZWNjb21wLWZpbHRlci5icGYgc2VjY29tcC1maWx0ZXIucGZj
CitlbmRpZgorCiAjIyBNYWtlZmlsZSBlbmRzIGhlcmUuCmRpZmYgLS1naXQgYS9saWItc3JjL3Nl
Y2NvbXAtZmlsdGVyLmMgYi9saWItc3JjL3NlY2NvbXAtZmlsdGVyLmMKbmV3IGZpbGUgbW9kZSAx
MDA2NDQKaW5kZXggMDAwMDAwMDAwMC4uZTBmZWEwYjQyMQotLS0gL2Rldi9udWxsCisrKyBiL2xp
Yi1zcmMvc2VjY29tcC1maWx0ZXIuYwpAQCAtMCwwICsxLDMwMyBAQAorLyogR2VuZXJhdGUgYSBT
ZWN1cmUgQ29tcHV0aW5nIGZpbHRlciBkZWZpbml0aW9uIGZpbGUuCisKK0NvcHlyaWdodCAoQykg
MjAyMCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKworVGhpcyBmaWxlIGlzIHBhcnQg
b2YgR05VIEVtYWNzLgorCitHTlUgRW1hY3MgaXMgZnJlZSBzb2Z0d2FyZTogeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdCB1bmRlciB0aGUKK3Rlcm1zIG9mIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUK
K0ZvdW5kYXRpb24sIGVpdGhlciB2ZXJzaW9uIDMgb2YgdGhlIExpY2Vuc2UsIG9yIChhdCB5b3Vy
IG9wdGlvbikgYW55IGxhdGVyCit2ZXJzaW9uLgorCitHTlUgRW1hY3MgaXMgZGlzdHJpYnV0ZWQg
aW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQgQU5ZCitXQVJS
QU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mIE1FUkNIQU5UQUJJTElU
WSBvciBGSVRORVNTIEZPUiBBCitQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisKK1lvdSBzaG91bGQgaGF2ZSBy
ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFsb25nIHdp
dGggR05VCitFbWFjcy4gIElmIG5vdCwgc2VlIDxodHRwczovL3d3dy5nbnUub3JnL2xpY2Vuc2Vz
Lz4uICAqLworCisvKiBUaGlzIHByb2dyYW0gY3JlYXRlcyBhIHNtYWxsIFNlY3VyZSBDb21wdXRp
bmcgZmlsdGVyIHVzYWJsZSBmb3IgYSB0eXBpY2FsCittaW5pbWFsIEVtYWNzIHNhbmRib3guICBT
ZWUgdGhlIG1hbiBwYWdlIGZvciBgc2VjY29tcCcgZm9yIGRldGFpbHMgYWJvdXQgU2VjdXJlCitD
b21wdXRpbmcgZmlsdGVycy4gIFRoaXMgcHJvZ3JhbSByZXF1aXJlcyB0aGUgYGxpYnNlY2NvbXAn
IGxpYnJhcnkuICBIb3dldmVyLAordGhlIHJlc3VsdGluZyBmaWx0ZXIgZmlsZSByZXF1aXJlcyBv
bmx5IGEgTGludXgga2VybmVsIHN1cHBvcnRpbmcgdGhlIFNlY3VyZQorQ29tcHV0aW5nIGV4dGVu
c2lvbi4KKworVXNhZ2U6CisKKyAgc2VjY29tcC1maWx0ZXIgb3V0LmJwZiBvdXQucGZjCisKK1Ro
aXMgd3JpdGVzIHRoZSByYXcgYHN0cnVjdCBzb2NrX2ZpbHRlcicgYXJyYXkgdG8gb3V0LmJwZiBh
bmQgYSBodW1hbi1yZWFkYWJsZQorcmVwcmVzZW50YXRpb24gdG8gb3V0LnBmYy4gICovCisKKyNp
bmNsdWRlICJjb25maWcuaCIKKworI2luY2x1ZGUgPGVycm5vLmg+CisjaW5jbHVkZSA8bGltaXRz
Lmg+CisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3RkYm9vbC5oPgorI2luY2x1ZGUg
PHN0ZGxpYi5oPgorI2luY2x1ZGUgPHN0ZGludC5oPgorI2luY2x1ZGUgPHN0ZGlvLmg+CisKKyNp
bmNsdWRlIDxzeXMvaW9jdGwuaD4KKyNpbmNsdWRlIDxzeXMvbW1hbi5oPgorI2luY2x1ZGUgPHN5
cy9wcmN0bC5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+
CisjaW5jbHVkZSA8bGludXgvZnV0ZXguaD4KKyNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUg
PHNjaGVkLmg+CisjaW5jbHVkZSA8c2VjY29tcC5oPgorI2luY2x1ZGUgPHVuaXN0ZC5oPgorCisj
aW5jbHVkZSAidmVyaWZ5LmgiCisKK3N0YXRpYyBBVFRSSUJVVEVfRk9STUFUX1BSSU5URiAoMiwg
MykgX05vcmV0dXJuIHZvaWQKK2ZhaWwgKGludCBlcnJvciwgY29uc3QgY2hhciAqZm9ybWF0LCAu
Li4pCit7CisgIHZhX2xpc3QgYXA7CisgIHZhX3N0YXJ0IChhcCwgZm9ybWF0KTsKKyAgaWYgKGVy
cm9yID09IDApCisgICAgdmZwcmludGYgKHN0ZGVyciwgZm9ybWF0LCBhcCk7CisgIGVsc2UKKyAg
ICB7CisgICAgICBjaGFyIGJ1ZmZlclsxMDAwXTsKKyAgICAgIHZzbnByaW50ZiAoYnVmZmVyLCBz
aXplb2YgYnVmZmVyLCBmb3JtYXQsIGFwKTsKKyAgICAgIGVycm5vID0gZXJyb3I7CisgICAgICBw
ZXJyb3IgKGJ1ZmZlcik7CisgICAgfQorICB2YV9lbmQgKGFwKTsKKyAgZmZsdXNoIChOVUxMKTsK
KyAgZXhpdCAoRVhJVF9GQUlMVVJFKTsKK30KKworLyogVGhpcyBiaW5hcnkgaXMgdHJpdmlhbCwg
c28gd2UgdXNlIGEgc2luZ2xlIGdsb2JhbCBmaWx0ZXIgY29udGV4dCBvYmplY3QgdGhhdAorICAg
d2UgcmVsZWFzZSB1c2luZyBgYXRleGl0Jy4gICovCisKK3N0YXRpYyBzY21wX2ZpbHRlcl9jdHgg
Y3R4OworCitzdGF0aWMgdm9pZAorcmVsZWFzZV9jb250ZXh0ICh2b2lkKQoreworICBzZWNjb21w
X3JlbGVhc2UgKGN0eCk7Cit9CisKKy8qIFdyYXBwZXIgZnVuY3Rpb25zIGFuZCBtYWNyb3MgZm9y
IGxpYnNlY2NvbXAgZnVuY3Rpb25zLiAgV2UgZXhpdCBpbW1lZGlhdGVseQorICAgdXBvbiBhbnkg
ZXJyb3IgdG8gYXZvaWQgZXJyb3IgY2hlY2tpbmcgbm9pc2UuICAqLworCitzdGF0aWMgdm9pZAor
c2V0X2F0dHJpYnV0ZSAoZW51bSBzY21wX2ZpbHRlcl9hdHRyIGF0dHIsIHVpbnQzMl90IHZhbHVl
KQoreworICBpbnQgc3RhdHVzID0gc2VjY29tcF9hdHRyX3NldCAoY3R4LCBhdHRyLCB2YWx1ZSk7
CisgIGlmIChzdGF0dXMgPCAwKQorICAgIGZhaWwgKC1zdGF0dXMsICJzZWNjb21wX2F0dHJfc2V0
IChjdHgsICV1LCAldSkiLCBhdHRyLCB2YWx1ZSk7Cit9CisKKy8qIExpa2UgYHNlY2NvbXBfcnVs
ZV9hZGQgKEFDVElPTiwgU1lTQ0FMTCwgLi4uKScsIGV4Y2VwdCB0aGF0IHlvdSBkb24ndCBoYXZl
IHRvCisgICBzcGVjaWZ5IHRoZSBudW1iZXIgb2YgY29tcGFyYXRvciBhcmd1bWVudHMsIGFuZCBh
bnkgZmFpbHVyZSB3aWxsIGV4aXQgdGhlCisgICBwcm9jZXNzLiAgKi8KKworI2RlZmluZSBSVUxF
KGFjdGlvbiwgc3lzY2FsbCwgLi4uKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICBkbyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgXAorICAgIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgY29uc3Qgc3Ry
dWN0IHNjbXBfYXJnX2NtcCBhcmdfYXJyYXlbXSA9IHtfX1ZBX0FSR1NfX307ICAgICAgICAgICAg
XAorICAgICAgZW51bSB7IGFyZ19jbnQgPSBzaXplb2YgYXJnX2FycmF5IC8gc2l6ZW9mICphcmdf
YXJyYXkgfTsgICAgICAgICAgXAorICAgICAgaW50IHN0YXR1cyA9IHNlY2NvbXBfcnVsZV9hZGRf
YXJyYXkgKGN0eCwgKGFjdGlvbiksIChzeXNjYWxsKSwgICAgXAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGFyZ19jbnQsIGFyZ19hcnJheSk7ICAgICAgICAgXAor
ICAgICAgaWYgKHN0YXR1cyA8IDApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAorICAgICAgICBmYWlsICgtc3RhdHVzLCAic2VjY29tcF9ydWxlX2Fk
ZF9hcnJheSAoJXMsICVzLCAlZCwgeyVzfSkiLAlcCisJICAgICAgI2FjdGlvbiwgI3N5c2NhbGws
IGFyZ19jbnQsICNfX1ZBX0FSR1NfXyk7CQlcCisgICAgfSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgIHdoaWxlIChm
YWxzZSkKKworc3RhdGljIHZvaWQKK2V4cG9ydF9maWx0ZXIgKGNvbnN0IGNoYXIgKmZpbGUsIGlu
dCAoKmZ1bmN0aW9uKSAoY29uc3Qgc2NtcF9maWx0ZXJfY3R4LCBpbnQpLAorICAgICAgICAgICAg
ICAgY29uc3QgY2hhciAqbmFtZSkKK3sKKyAgaW50IGZkID0gVEVNUF9GQUlMVVJFX1JFVFJZICgK
KyAgICBvcGVuIChmaWxlLCBPX1dST05MWSB8IE9fQ1JFQVQgfCBPX1RSVU5DIHwgT19CSU5BUlkg
fCBPX0NMT0VYRUMsIDA2NDQpKTsKKyAgaWYgKGZkIDwgMCkKKyAgICBmYWlsIChlcnJubywgIm9w
ZW4gJXMiLCBmaWxlKTsKKyAgaW50IHN0YXR1cyA9IGZ1bmN0aW9uIChjdHgsIGZkKTsKKyAgaWYg
KHN0YXR1cyA8IDApCisgICAgZmFpbCAoLXN0YXR1cywgIiVzIiwgbmFtZSk7CisgIGlmIChjbG9z
ZSAoZmQpICE9IDApCisgICAgZmFpbCAoZXJybm8sICJjbG9zZSIpOworfQorCisjZGVmaW5lIEVY
UE9SVF9GSUxURVIoZmlsZSwgZnVuY3Rpb24pIFwKKyAgZXhwb3J0X2ZpbHRlciAoKGZpbGUpLCAo
ZnVuY3Rpb24pLCAjZnVuY3Rpb24pCisKK2ludAorbWFpbiAoaW50IGFyZ2MsIGNoYXIgKiphcmd2
KQoreworICBpZiAoYXJnYyAhPSAzKQorICAgIGZhaWwgKDAsICJ1c2FnZTogJXMgb3V0LmJwZiBv
dXQucGZjIiwgYXJndlswXSk7CisKKyAgLyogQW55IHVuaGFuZGxlZCBzeXNjYWxsIHNob3VsZCBh
Ym9ydCB0aGUgRW1hY3MgcHJvY2Vzcy4gICovCisgIGN0eCA9IHNlY2NvbXBfaW5pdCAoU0NNUF9B
Q1RfS0lMTF9QUk9DRVNTKTsKKyAgaWYgKGN0eCA9PSBOVUxMKQorICAgIGZhaWwgKDAsICJzZWNj
b21wX2luaXQiKTsKKyAgYXRleGl0IChyZWxlYXNlX2NvbnRleHQpOworCisgIC8qIFdlIHdhbnQg
dG8gYWJvcnQgaW1tZWRpYXRlbHkgaWYgdGhlIGFyY2hpdGVjdHVyZSBpcyB1bmtub3duLiAgKi8K
KyAgc2V0X2F0dHJpYnV0ZSAoU0NNUF9GTFRBVFJfQUNUX0JBREFSQ0gsIFNDTVBfQUNUX0tJTExf
UFJPQ0VTUyk7CisgIHNldF9hdHRyaWJ1dGUgKFNDTVBfRkxUQVRSX0NUTF9OTlAsIDEpOworICBz
ZXRfYXR0cmlidXRlIChTQ01QX0ZMVEFUUl9DVExfVFNZTkMsIDEpOworICBzZXRfYXR0cmlidXRl
IChTQ01QX0ZMVEFUUl9DVExfTE9HLCAwKTsKKworICB2ZXJpZnkgKENIQVJfQklUID09IDgpOwor
ICB2ZXJpZnkgKHNpemVvZiAoaW50KSA9PSA0ICYmIElOVF9NSU4gPT0gSU5UMzJfTUlOICYmIElO
VF9NQVggPT0gSU5UMzJfTUFYKTsKKyAgdmVyaWZ5IChzaXplb2YgKHZvaWQgKikgPT0gOCk7Cisg
IHZlcmlmeSAoKHVpbnRwdHJfdCkgTlVMTCA9PSAwKTsKKworICAvKiBBbGxvdyBhIGNsZWFuIGV4
aXQuICAqLworICBSVUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMgKGV4aXQpKTsKKyAgUlVM
RSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChleGl0X2dyb3VwKSk7CisKKyAgLyogQWxsb3cg
YG1tYXAnIGFuZCBmcmllbmRzLiAgVGhpcyBpcyBuZWNlc3NhcnkgZm9yIGR5bmFtaWMgbG9hZGlu
ZywgcmVhZGluZworICAgICB0aGUgcG9ydGFibGUgZHVtcCBmaWxlLCBhbmQgdGhyZWFkIGNyZWF0
aW9uLiAgV2UgZG9uJ3QgYWxsb3cgcGFnZXMgdG8gYmUKKyAgICAgYm90aCB3cml0YWJsZSBhbmQg
ZXhlY3V0YWJsZS4gICovCisgIHZlcmlmeSAoTUFQX1BSSVZBVEUgIT0gMCk7CisgIHZlcmlmeSAo
TUFQX1NIQVJFRCAhPSAwKTsKKyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChtbWFw
KSwKKyAgICAgICAgU0NNUF9BMl8zMiAoU0NNUF9DTVBfTUFTS0VEX0VRLCB+KFBST1RfTk9ORSB8
IFBST1RfUkVBRCB8IFBST1RfV1JJVEUpKSwKKyAgICAgICAgLyogT25seSBzdXBwb3J0IGtub3du
IGZsYWdzLiAgTUFQX0RFTllXUklURSBpcyBpZ25vcmVkLCBidXQgc29tZQorICAgICAgICAgICB2
ZXJzaW9ucyBvZiB0aGUgZHluYW1pYyBsb2FkZXIgc3RpbGwgdXNlIGl0LiAgQWxzbyBhbGxvdyBh
bGxvY2F0aW5nCisgICAgICAgICAgIHRocmVhZCBzdGFja3MuICAqLworICAgICAgICBTQ01QX0Ez
XzMyIChTQ01QX0NNUF9NQVNLRURfRVEsCisgICAgICAgICAgICAgICAgICAgIH4oTUFQX1BSSVZB
VEUgfCBNQVBfRklMRSB8IE1BUF9BTk9OWU1PVVMgfCBNQVBfRklYRUQKKyAgICAgICAgICAgICAg
ICAgICAgICB8IE1BUF9ERU5ZV1JJVEUgfCBNQVBfU1RBQ0sgfCBNQVBfTk9SRVNFUlZFKSwKKyAg
ICAgICAgICAgICAgICAgICAgMCkpOworICBSVUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMg
KG1tYXApLAorICAgICAgICBTQ01QX0EyXzMyIChTQ01QX0NNUF9NQVNLRURfRVEsIH4oUFJPVF9O
T05FIHwgUFJPVF9SRUFEIHwgUFJPVF9FWEVDKSksCisgICAgICAgIC8qIE9ubHkgc3VwcG9ydCBr
bm93biBmbGFncy4gIE1BUF9ERU5ZV1JJVEUgaXMgaWdub3JlZCwgYnV0IHNvbWUKKyAgICAgICAg
ICAgdmVyc2lvbnMgb2YgdGhlIGR5bmFtaWMgbG9hZGVyIHN0aWxsIHVzZSBpdC4gKi8KKyAgICAg
ICAgU0NNUF9BM18zMiAoU0NNUF9DTVBfTUFTS0VEX0VRLAorICAgICAgICAgICAgICAgICAgICB+
KE1BUF9QUklWQVRFIHwgTUFQX0FOT05ZTU9VUyB8IE1BUF9GSVhFRCB8IE1BUF9ERU5ZV1JJVEUp
LAorICAgICAgICAgICAgICAgICAgICAwKSk7CisgIFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01Q
X1NZUyAobXVubWFwKSk7CisgIFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAobXByb3Rl
Y3QpLAorCS8qIERvbid0IGFsbG93IG1ha2luZyBwYWdlcyBleGVjdXRhYmxlLiAgKi8KKyAgICAg
ICAgU0NNUF9BMl8zMiAoU0NNUF9DTVBfTUFTS0VEX0VRLCB+KFBST1RfTk9ORSB8IFBST1RfUkVB
RCB8IFBST1RfV1JJVEUpLAorICAgICAgICAgICAgICAgICAgICAwKSk7CisKKyAgLyogRnV0ZXhl
cyBhcmUgdXNlZCBldmVyeXdoZXJlLiAgKi8KKyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBf
U1lTIChmdXRleCksCisgICAgICAgIFNDTVBfQTFfMzIgKFNDTVBfQ01QX0VRLCBGVVRFWF9XQUtF
X1BSSVZBVEUpKTsKKworICAvKiBBbGxvdyBiYXNpYyBkeW5hbWljIG1lbW9yeSBtYW5hZ2VtZW50
LiAgKi8KKyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChicmspKTsKKworICAvKiBB
bGxvdyBzb21lIHN0YXR1cyBpbnF1aXJpZXMuICAqLworICBSVUxFIChTQ01QX0FDVF9BTExPVywg
U0NNUF9TWVMgKHVuYW1lKSk7CisgIFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAoZ2V0
dWlkKSk7CisgIFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAoZ2V0ZXVpZCkpOworICBS
VUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMgKGdldHBpZCkpOworICBSVUxFIChTQ01QX0FD
VF9BTExPVywgU0NNUF9TWVMgKGdldHBncnApKTsKKworICAvKiBBbGxvdyBvcGVyYXRpb25zIG9u
IG9wZW4gZmlsZSBkZXNjcmlwdG9ycy4gIEZpbGUgZGVzY3JpcHRvcnMgYXJlCisgICAgIGNhcGFi
aWxpdGllcywgYW5kIG9wZXJhdGluZyBvbiB0aGVtIHNob3VsZG4ndCBjYXVzZSBzZWN1cml0eSBp
c3N1ZXMuICAqLworICBSVUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMgKHJlYWQpKTsKKyAg
UlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTICh3cml0ZSkpOworICBSVUxFIChTQ01QX0FD
VF9BTExPVywgU0NNUF9TWVMgKGNsb3NlKSk7CisgIFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01Q
X1NZUyAobHNlZWspKTsKKyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChkdXApKTsK
KyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChkdXAyKSk7CisgIFJVTEUgKFNDTVBf
QUNUX0FMTE9XLCBTQ01QX1NZUyAoZnN0YXQpKTsKKworICAvKiBBbGxvdyByZWFkIG9wZXJhdGlv
bnMgb24gdGhlIGZpbGVzeXN0ZW0uICBJZiBuZWNlc3NhcnksIHRoZXNlIHNob3VsZCBiZQorICAg
ICBmdXJ0aGVyIHJlc3RyaWN0ZWQgdXNpbmcgbW91bnQgbmFtZXNwYWNlcy4gICovCisgIFJVTEUg
KFNDTVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAoYWNjZXNzKSk7CisgIFJVTEUgKFNDTVBfQUNUX0FM
TE9XLCBTQ01QX1NZUyAoZmFjY2Vzc2F0KSk7CisgIFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01Q
X1NZUyAoc3RhdCkpOworICBSVUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMgKHN0YXQ2NCkp
OworICBSVUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMgKGxzdGF0KSk7CisgIFJVTEUgKFND
TVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAobHN0YXQ2NCkpOworICBSVUxFIChTQ01QX0FDVF9BTExP
VywgU0NNUF9TWVMgKGZzdGF0YXQ2NCkpOworICBSVUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9T
WVMgKG5ld2ZzdGF0YXQpKTsKKyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChyZWFk
bGluaykpOworICBSVUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMgKHJlYWRsaW5rYXQpKTsK
KyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChnZXRjd2QpKTsKKworICAvKiBBbGxv
dyBvcGVuaW5nIGZpbGVzLCBhc3N1bWluZyB0aGV5IGFyZSBvbmx5IG9wZW5lZCBmb3IgcmVhZGlu
Zy4gICovCisgIHZlcmlmeSAoT19XUk9OTFkgIT0gMCk7CisgIHZlcmlmeSAoT19SRFdSICE9IDAp
OworICB2ZXJpZnkgKE9fQ1JFQVQgIT0gMCk7CisgIFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01Q
X1NZUyAob3BlbiksCisgICAgICAgIFNDTVBfQTFfMzIgKFNDTVBfQ01QX01BU0tFRF9FUSwKKyAg
ICAgICAgICAgICAgICAgICAgfihPX1JET05MWSB8IE9fQklOQVJZIHwgT19DTE9FWEVDIHwgT19Q
QVRIIHwgT19ESVJFQ1RPUlkpLAorICAgICAgICAgICAgICAgICAgICAwKSk7CisgIFJVTEUgKFND
TVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAob3BlbmF0KSwKKyAgICAgICAgU0NNUF9BMl8zMiAoU0NN
UF9DTVBfTUFTS0VEX0VRLAorICAgICAgICAgICAgICAgICAgICB+KE9fUkRPTkxZIHwgT19CSU5B
UlkgfCBPX0NMT0VYRUMgfCBPX1BBVEggfCBPX0RJUkVDVE9SWSksCisgICAgICAgICAgICAgICAg
ICAgIDApKTsKKworICAvKiBBbGxvdyBgdGNnZXRwZ3JwJy4gICovCisgIFJVTEUgKFNDTVBfQUNU
X0FMTE9XLCBTQ01QX1NZUyAoaW9jdGwpLCBTQ01QX0EwXzMyIChTQ01QX0NNUF9FUSwgU1RESU5f
RklMRU5PKSwKKyAgICAgICAgU0NNUF9BMV8zMiAoU0NNUF9DTVBfRVEsIFRJT0NHUEdSUCkpOwor
CisgIC8qIEFsbG93IHJlYWRpbmcgKGJ1dCBub3Qgc2V0dGluZykgZmlsZSBmbGFncy4gICovCisg
IFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAoZmNudGwpLCBTQ01QX0ExXzMyIChTQ01Q
X0NNUF9FUSwgRl9HRVRGTCkpOworICBSVUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMgKGZj
bnRsNjQpLCBTQ01QX0ExXzMyIChTQ01QX0NNUF9FUSwgRl9HRVRGTCkpOworCisgIC8qIEFsbG93
IHJlYWRpbmcgcmFuZG9tIG51bWJlcnMgZnJvbSB0aGUga2VybmVsLiAgKi8KKyAgUlVMRSAoU0NN
UF9BQ1RfQUxMT1csIFNDTVBfU1lTIChnZXRyYW5kb20pKTsKKworICAvKiBDaGFuZ2luZyB0aGUg
dW1hc2sgaXMgdW5jcml0aWNhbC4gICovCisgIFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01QX1NZ
UyAodW1hc2spKTsKKworICAvKiBBbGxvdyBjcmVhdGlvbiBvZiBwaXBlcy4gICovCisgIFJVTEUg
KFNDTVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAocGlwZSkpOworICBSVUxFIChTQ01QX0FDVF9BTExP
VywgU0NNUF9TWVMgKHBpcGUyKSk7CisKKyAgLyogQWxsb3cgcmVhZGluZyAoYnV0IG5vdCBjaGFu
Z2luZykgcmVzb3VyY2UgbGltaXRzLiAgKi8KKyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBf
U1lTIChnZXRybGltaXQpKTsKKyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChwcmxp
bWl0NjQpLAorCVNDTVBfQTBfMzIgKFNDTVBfQ01QX0VRLCAwKSAvKiBwaWQgPT0gMCAoY3VycmVu
dCBwcm9jZXNzKSAqLywKKyAgICAgICAgU0NNUF9BMl82NCAoU0NNUF9DTVBfRVEsIDApIC8qIG5l
d19saW1pdCA9PSBOVUxMICovKTsKKworICAvKiBCbG9jayBjaGFuZ2luZyByZXNvdXJjZSBsaW1p
dHMsIGJ1dCBkb24ndCBjcmFzaC4gICovCisgIFJVTEUgKFNDTVBfQUNUX0VSUk5PIChFUEVSTSks
IFNDTVBfU1lTIChwcmxpbWl0NjQpLAorICAgICAgICBTQ01QX0EwXzMyIChTQ01QX0NNUF9FUSwg
MCkgLyogcGlkID09IDAgKGN1cnJlbnQgcHJvY2VzcykgKi8sCisgICAgICAgIFNDTVBfQTJfNjQg
KFNDTVBfQ01QX05FLCAwKSAvKiBuZXdfbGltaXQgIT0gTlVMTCAqLyk7CisKKyAgLyogRW1hY3Mg
aW5zdGFsbHMgc2lnbmFsIGhhbmRsZXJzLCB3aGljaCBpcyBoYXJtbGVzcy4gICovCisgIFJVTEUg
KFNDTVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAoc2lnYWN0aW9uKSk7CisgIFJVTEUgKFNDTVBfQUNU
X0FMTE9XLCBTQ01QX1NZUyAocnRfc2lnYWN0aW9uKSk7CisgIFJVTEUgKFNDTVBfQUNUX0FMTE9X
LCBTQ01QX1NZUyAoc2lncHJvY21hc2spKTsKKyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBf
U1lTIChydF9zaWdwcm9jbWFzaykpOworCisgIC8qIEFsbG93IHRpbWVyIHN1cHBvcnQuICAqLwor
ICBSVUxFIChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMgKHRpbWVyX2NyZWF0ZSkpOworICBSVUxF
IChTQ01QX0FDVF9BTExPVywgU0NNUF9TWVMgKHRpbWVyZmRfY3JlYXRlKSk7CisKKyAgLyogQWxs
b3cgdGhyZWFkIGNyZWF0aW9uLiAgU2VlIHRoZSBOT1RFUyBzZWN0aW9uIGluIHRoZSBtYW51YWwg
cGFnZSBmb3IgdGhlCisgICAgIGBjbG9uZScgZnVuY3Rpb24uICAqLworICBSVUxFIChTQ01QX0FD
VF9BTExPVywgU0NNUF9TWVMgKGNsb25lKSwKKyAgICAgICAgU0NNUF9BMF82NCAoU0NNUF9DTVBf
TUFTS0VEX0VRLAorCQkgICAgLyogRmxhZ3MgbmVlZGVkIHRvIGNyZWF0ZSB0aHJlYWRzLiAgU2Vl
IGNyZWF0ZV90aHJlYWQgaW4KKwkJICAgICAgIGxpYmMuICAqLworICAgICAgICAgICAgICAgICAg
ICB+KENMT05FX1ZNIHwgQ0xPTkVfRlMgfCBDTE9ORV9GSUxFUyB8IENMT05FX1NZU1ZTRU0KKyAg
ICAgICAgICAgICAgICAgICAgICB8IENMT05FX1NJR0hBTkQgfCBDTE9ORV9USFJFQUQgfCBDTE9O
RV9TRVRUTFMKKyAgICAgICAgICAgICAgICAgICAgICB8IENMT05FX1BBUkVOVF9TRVRUSUQgfCBD
TE9ORV9DSElMRF9DTEVBUlRJRCksCisgICAgICAgICAgICAgICAgICAgIDApKTsKKyAgUlVMRSAo
U0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChzaWdhbHRzdGFjaykpOworICBSVUxFIChTQ01QX0FD
VF9BTExPVywgU0NNUF9TWVMgKHNldF9yb2J1c3RfbGlzdCkpOworCisgIC8qIEFsbG93IHNldHRp
bmcgdGhlIHByb2Nlc3MgbmFtZSBmb3IgbmV3IHRocmVhZHMuICAqLworICBSVUxFIChTQ01QX0FD
VF9BTExPVywgU0NNUF9TWVMgKHByY3RsKSwgU0NNUF9BMF8zMiAoU0NNUF9DTVBfRVEsIFBSX1NF
VF9OQU1FKSk7CisKKyAgLyogQWxsb3cgc29tZSBldmVudCBoYW5kbGluZyBmdW5jdGlvbnMgdXNl
ZCBieSBnbGliLiAgKi8KKyAgUlVMRSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTIChldmVudGZk
KSk7CisgIFJVTEUgKFNDTVBfQUNUX0FMTE9XLCBTQ01QX1NZUyAoZXZlbnRmZDIpKTsKKyAgUlVM
RSAoU0NNUF9BQ1RfQUxMT1csIFNDTVBfU1lTICh3YWl0NCkpOworICBSVUxFIChTQ01QX0FDVF9B
TExPVywgU0NNUF9TWVMgKHBvbGwpKTsKKworICAvKiBEb24ndCBhbGxvdyBjcmVhdGluZyBzb2Nr
ZXRzIChuZXR3b3JrIGFjY2VzcyB3b3VsZCBiZSBleHRyZW1lbHkgZGFuZ2Vyb3VzKSwKKyAgICAg
YnV0IGFsc28gZG9uJ3QgY3Jhc2guICAqLworICBSVUxFIChTQ01QX0FDVF9FUlJOTyAoRUFDQ0VT
KSwgU0NNUF9TWVMgKHNvY2tldCkpOworCisgIEVYUE9SVF9GSUxURVIgKGFyZ3ZbMV0sIHNlY2Nv
bXBfZXhwb3J0X2JwZik7CisgIEVYUE9SVF9GSUxURVIgKGFyZ3ZbMl0sIHNlY2NvbXBfZXhwb3J0
X3BmYyk7Cit9CmRpZmYgLS1naXQgYS90ZXN0L01ha2VmaWxlLmluIGIvdGVzdC9NYWtlZmlsZS5p
bgppbmRleCA2N2QyMDNkZjI5Li45OWY2OWY3ZmNkIDEwMDY0NAotLS0gYS90ZXN0L01ha2VmaWxl
LmluCisrKyBiL3Rlc3QvTWFrZWZpbGUuaW4KQEAgLTI3MSw2ICsyNzEsOCBAQCAkKHRlc3RfbW9k
dWxlKTogJCh0ZXN0X21vZHVsZToKIAkgICQoc3JjZGlyKS8uLi9saWIvdGltZXNwZWMuYyAkKHNy
Y2RpcikvLi4vbGliL2dldHRpbWUuYwogZW5kaWYKIAorc3JjL2VtYWNzLXRlc3RzLmxvZzogLi4v
bGliLXNyYy9zZWNjb21wLWZpbHRlci5jCisKICMjIENoZWNrIHRoYXQgdGhlcmUgaXMgbm8gJ2F1
dG9tYXRlZCcgc3ViZGlyZWN0b3J5LCB3aGljaCB3b3VsZAogIyMgaW5kaWNhdGUgYW4gaW5jb21w
bGV0ZSBtZXJnZSBmcm9tIGFuIG9sZGVyIHZlcnNpb24gb2YgRW1hY3Mgd2hlcmUKICMjIHRoZSB0
ZXN0cyB3ZXJlIGFycmFuZ2VkIGRpZmZlcmVudGx5LgpkaWZmIC0tZ2l0IGEvdGVzdC9zcmMvZW1h
Y3MtcmVzb3VyY2VzL3NlY2NvbXAtZmlsdGVyLmJwZiBiL3Rlc3Qvc3JjL2VtYWNzLXJlc291cmNl
cy9zZWNjb21wLWZpbHRlci5icGYKbmV3IGZpbGUgbW9kZSAxMjAwMDAKaW5kZXggMDAwMDAwMDAw
MC4uYjNkNjAzZDBhZQotLS0gL2Rldi9udWxsCisrKyBiL3Rlc3Qvc3JjL2VtYWNzLXJlc291cmNl
cy9zZWNjb21wLWZpbHRlci5icGYKQEAgLTAsMCArMSBAQAorLi4vLi4vLi4vbGliLXNyYy9zZWNj
b21wLWZpbHRlci5icGYKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCmRpZmYgLS1naXQgYS90
ZXN0L3NyYy9lbWFjcy10ZXN0cy5lbCBiL3Rlc3Qvc3JjL2VtYWNzLXRlc3RzLmVsCmluZGV4IDI3
OWVjYjIxMGMuLjk1OTljMjY3ODMgMTAwNjQ0Ci0tLSBhL3Rlc3Qvc3JjL2VtYWNzLXRlc3RzLmVs
CisrKyBiL3Rlc3Qvc3JjL2VtYWNzLXRlc3RzLmVsCkBAIC0yNSw2ICsyNSw4IEBACiAKIChyZXF1
aXJlICdjbC1saWIpCiAocmVxdWlyZSAnZXJ0KQorKHJlcXVpcmUgJ2VydC14KQorKHJlcXVpcmUg
J3N1YnIteCkKIAogKGVydC1kZWZ0ZXN0IGVtYWNzLXRlc3RzL3NlY2NvbXAvYWJzZW50LWZpbGUg
KCkKICAgKGxldCAoKGVtYWNzIChleHBhbmQtZmlsZS1uYW1lIGludm9jYXRpb24tbmFtZSBpbnZv
Y2F0aW9uLWRpcmVjdG9yeSkpCkBAIC04Myw0ICs4NSw0NiBAQCBlbWFjcy10ZXN0cy9zZWNjb21w
L2ludmFsaWQtZmlsZS1zaXplCiAgICAgICAgICAgICAgICAgICAgICAgICAgICItLXF1aWNrIiAi
LS1iYXRjaCIgKGNvbmNhdCAiLS1zZWNjb21wPSIgZmlsdGVyKSkKICAgICAgICAgICAgIDApKSkp
KQogCisoZXJ0LWRlZnRlc3QgZW1hY3MtdGVzdHMvc2VjY29tcC9hbGxvd3Mtc3Rkb3V0ICgpCisg
IChsZXQgKChlbWFjcyAoZXhwYW5kLWZpbGUtbmFtZSBpbnZvY2F0aW9uLW5hbWUgaW52b2NhdGlv
bi1kaXJlY3RvcnkpKQorICAgICAgICAoZmlsdGVyIChlcnQtcmVzb3VyY2UtZmlsZSAic2VjY29t
cC1maWx0ZXIuYnBmIikpCisgICAgICAgIChwcm9jZXNzLWVudmlyb25tZW50IG5pbCkpCisgICAg
KHNraXAtdW5sZXNzIChmaWxlLWV4ZWN1dGFibGUtcCBlbWFjcykpCisgICAgKHNraXAtdW5sZXNz
IChmaWxlLXJlYWRhYmxlLXAgZmlsdGVyKSkKKyAgICA7OyBUaGUgLS1zZWNjb21wIG9wdGlvbiBp
cyBwcm9jZXNzZWQgZWFybHksIHdpdGhvdXQgZmlsZW5hbWUgaGFuZGxlcnMuCisgICAgOzsgVGhl
cmVmb3JlIHJlbW90ZSBvciBxdW90ZWQgZmlsZW5hbWVzIHdvdWxkbid0IHdvcmsuCisgICAgKHNo
b3VsZC1ub3QgKGZpbGUtcmVtb3RlLXAgZmlsdGVyKSkKKyAgICAoY2wtY2FsbGYgZmlsZS1uYW1l
LXVucXVvdGUgZmlsdGVyKQorICAgICh3aXRoLXRlbXAtYnVmZmVyCisgICAgICAobGV0ICgoc3Rh
dHVzIChjYWxsLXByb2Nlc3MgZW1hY3MgbmlsIHQgbmlsCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIi0tcXVpY2siICItLWJhdGNoIgorICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIChjb25jYXQgIi0tc2VjY29tcD0iIGZpbHRlcikKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAoY29uY2F0ICItLWV2YWw9IiAocHJpbjEtdG8tc3RyaW5nCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICcobWVzc2Fn
ZSAiSGkiKSkpKSkpCisgICAgICAgIChlcnQtaW5mbyAoKGZvcm1hdCAiUHJvY2VzcyBvdXRwdXQ6
ICVzIiAoYnVmZmVyLXN0cmluZykpKQorICAgICAgICAgIChzaG91bGQgKGVxbCBzdGF0dXMgMCkp
KQorICAgICAgICAoc2hvdWxkIChlcXVhbCAoc3RyaW5nLXRyaW0gKGJ1ZmZlci1zdHJpbmcpKSAi
SGkiKSkpKSkpCisKKyhlcnQtZGVmdGVzdCBlbWFjcy10ZXN0cy9zZWNjb21wL2ZvcmJpZHMtc3Vi
cHJvY2VzcyAoKQorICAobGV0ICgoZW1hY3MgKGV4cGFuZC1maWxlLW5hbWUgaW52b2NhdGlvbi1u
YW1lIGludm9jYXRpb24tZGlyZWN0b3J5KSkKKyAgICAgICAgKGZpbHRlciAoZXJ0LXJlc291cmNl
LWZpbGUgInNlY2NvbXAtZmlsdGVyLmJwZiIpKQorICAgICAgICAocHJvY2Vzcy1lbnZpcm9ubWVu
dCBuaWwpKQorICAgIChza2lwLXVubGVzcyAoZmlsZS1leGVjdXRhYmxlLXAgZW1hY3MpKQorICAg
IChza2lwLXVubGVzcyAoZmlsZS1yZWFkYWJsZS1wIGZpbHRlcikpCisgICAgOzsgVGhlIC0tc2Vj
Y29tcCBvcHRpb24gaXMgcHJvY2Vzc2VkIGVhcmx5LCB3aXRob3V0IGZpbGVuYW1lIGhhbmRsZXJz
LgorICAgIDs7IFRoZXJlZm9yZSByZW1vdGUgb3IgcXVvdGVkIGZpbGVuYW1lcyB3b3VsZG4ndCB3
b3JrLgorICAgIChzaG91bGQtbm90IChmaWxlLXJlbW90ZS1wIGZpbHRlcikpCisgICAgKGNsLWNh
bGxmIGZpbGUtbmFtZS11bnF1b3RlIGZpbHRlcikKKyAgICAod2l0aC10ZW1wLWJ1ZmZlcgorICAg
ICAgKGxldCAoKHN0YXR1cworICAgICAgICAgICAgIChjYWxsLXByb2Nlc3MKKyAgICAgICAgICAg
ICAgZW1hY3MgbmlsIHQgbmlsCisgICAgICAgICAgICAgICItLXF1aWNrIiAiLS1iYXRjaCIKKyAg
ICAgICAgICAgICAgKGNvbmNhdCAiLS1zZWNjb21wPSIgZmlsdGVyKQorICAgICAgICAgICAgICAo
Y29uY2F0ICItLWV2YWw9IiAocHJpbjEtdG8tc3RyaW5nCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBgKGNhbGwtcHJvY2VzcyAsZW1hY3MgbmlsIG5pbCBuaWwKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICItLXZlcnNpb24iKSkpKSkpCisg
ICAgICAgIChlcnQtaW5mbyAoKGZvcm1hdCAiUHJvY2VzcyBvdXRwdXQ6ICVzIiAoYnVmZmVyLXN0
cmluZykpKQorICAgICAgICAgIChzaG91bGQtbm90IChlcWwgc3RhdHVzIDApKSkpKSkpCisKIDs7
OyBlbWFjcy10ZXN0cy5lbCBlbmRzIGhlcmUKLS0gCjIuMjkuMi43MjkuZzQ1ZGFmODc3N2QtZ29v
ZwoK
--00000000000080b8ad05b6d8a897--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 20:59:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 15:59:43 2020
Received: from localhost ([127.0.0.1]:43282 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqjKJ-00077d-Be
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 15:59:43 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46418)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kqjKF-00077O-V4
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 15:59:41 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8E2C2440326;
 Sat, 19 Dec 2020 15:59:34 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 494E2440318;
 Sat, 19 Dec 2020 15:59:33 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1608411573;
 bh=T6tnhodp8vjKylPsvfQnJcTA9N3RwrVHyI0kw8qqSwY=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=ZFAvZ/JzO2OHsIx71GRVTzPuaVKoAFR0HX7jRZW44hhsBs3GohsqlbAVtt6Nwkutp
 w7lTSQTQ3TOI2Bjr9fOJUx+fFVCWTxAk3cEa3TXvuqHAVdedG785tAI0QEg2z9vqua
 aCVnWE8PQqNWhgcTQ6pCaq50mq4Bhb5SksxW70TLAGSFW4OYmhJb2nuhJmXF19AVHX
 Ff61TWWDpFO2CIFj/WJz1nF8udkE1b6EHSWkU8mS8KMFyCUiAOUBVMyKQ8r4sg3yPJ
 E+nRpm7EdHZmeZU6b+zLxOWT00dBGo3lxA6dfvjrLjeHKpcgRCWrmv+NVcIbS1BCTz
 qo0KlHOPGJL8A==
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E96EC120257;
 Sat, 19 Dec 2020 15:59:32 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Mattias =?windows-1252?Q?Engdeg=E5rd?= <mattiase@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwvblepv7ex.fsf-monnier+emacs@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
 <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
 <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
 <jwvblepoeuq.fsf-monnier+emacs@HIDDEN>
 <239166D0-63F2-48CF-AC26-B306B99419BC@HIDDEN>
Date: Sat, 19 Dec 2020 16:01:38 -0500
In-Reply-To: <239166D0-63F2-48CF-AC26-B306B99419BC@HIDDEN> ("Mattias
 =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Sat, 19 Dec 2020 19:46:59
 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.073 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Philipp Stephani <p.stephani2@HIDDEN>,
 =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I must say I don't know what's being discussed here.
>> What autoloads?  Why do we care?
> If a user looks at elisp code that depends on autoloads and the checker
> process cannot load those for reasons of sandbox policy or whatnot, there
> will be false positives about missing functions. This is fine if we are
> phasing out autoloads but as far as I know we're not.

I don't understand why it would be different for autoloads than for
functions provided by `require`d packages.

Also, if we add all the dirs in `load-path` to the set of readable
directories (and I do think we want to do that) this should not be
an issue, right?


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 19:48:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 14:48:37 2020
Received: from localhost ([127.0.0.1]:43215 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqiDV-0003MZ-NU
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 14:48:37 -0500
Received: from mail-il1-f176.google.com ([209.85.166.176]:33921)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1kqiDT-0003ML-40
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 14:48:36 -0500
Received: by mail-il1-f176.google.com with SMTP id x15so5409020ilq.1
 for <45198 <at> debbugs.gnu.org>; Sat, 19 Dec 2020 11:48:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=1k6MgMtYS4wnZWFzDZNs7UGxALsIbQszvy+xG3X2kf0=;
 b=QLvEAPfh2ZjxkkozW2Zn1shm6+Cju34myG7456WYb3M53ZDXGPTXMhRXZGAL826d7t
 +nM+XX4TrQLlUqdQo3tAZpNCVeF4Bt3LTTU2sqYsixaOTnBY2vQDdH85aKsAbke2umqf
 8LnMqfrFIrCANXVln6v7ax+PdNt6REqz1cnkoRhWLPFxQryswUTDNUuGulHyNsVF8q2s
 H7Bg3BLrIm6gyh06L/HBJciNnOp0oeZv8tsa1hGvwyubzrJxEtKyIUQenIeoOQBX+WqO
 yDf3npl+uSIJ9BCV1g/B6HpJlnLmtnZlWHjFfcqdBp+/1bS0V4TYaHPF9z6x/3akV5Jo
 uI/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=1k6MgMtYS4wnZWFzDZNs7UGxALsIbQszvy+xG3X2kf0=;
 b=Y2tFrkZVSS4Ai8tqw4GIOoE5w11eTkC5aoU3US0tA6E1GvXLND2d2QtbnBilwAG+hU
 goH4EiQpQTmp8gBsne+Tq0n0s9nVRqnPze64H5EcuZpptdxTA4tbNpY6HeGYt/7ftodu
 r20WW5MzNQvdvmHXBZ0b2ttg9QIlKU8gAx7F7f8aGuLUSE5HtV5z6gxDaCH/FHthp9GB
 OkMVKDVmhSZYzpUDJXf8oceMgtCcI/0E2yFrX41kPWnYF0ZMGoWJC6gUygffh+BhJikA
 LJnskUQHjD1v0hxygUS+o1ozzEC+42HUPOweB8h/MU85AO9XBP9Bn57b6+3m2xpjAfPG
 6L0A==
X-Gm-Message-State: AOAM531HkgCbhJT7jwAoF7JmM22JJydetRb1pOhQi9ATxb3NmovQovlh
 U4aOEowFDI+BeJ3G8tv67pM2ZRQ8dDenPUCHdPY=
X-Google-Smtp-Source: ABdhPJwjtN2AQ2grz3ohqbL6s+qoxtPWYf4AkUpfgY/NL84oh4c0DZTiOwht4bM04Np9UOv0oHmLplnl+kFE5nIvsUE=
X-Received: by 2002:a05:6e02:14ce:: with SMTP id
 o14mr10335447ilk.9.1608407309339; 
 Sat, 19 Dec 2020 11:48:29 -0800 (PST)
MIME-Version: 1.0
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
 <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
 <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
 <jwvblepoeuq.fsf-monnier+emacs@HIDDEN>
 <239166D0-63F2-48CF-AC26-B306B99419BC@HIDDEN>
In-Reply-To: <239166D0-63F2-48CF-AC26-B306B99419BC@HIDDEN>
From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Date: Sat, 19 Dec 2020 19:48:18 +0000
Message-ID: <CALDnm51Z3Kq0b8CLC6kn1=xmn79HBbzs_yuB=0MxHgD=Kz4pPw@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Philipp Stephani <p.stephani2@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Sat, Dec 19, 2020 at 6:47 PM Mattias Engdeg=C3=A5rd <mattiase@HIDDEN> w=
rote:
>
> 19 dec. 2020 kl. 19.11 skrev Stefan Monnier <monnier@HIDDEN>:
>
> > I must say I don't know what's being discussed here.
> > What autoloads?  Why do we care?
>
> If a user looks at elisp code that depends on autoloads and the checker p=
rocess cannot load those for reasons of sandbox policy or whatnot, there wi=
ll be false positives about missing functions. This is fine if we are phasi=
ng out autoloads but as far as I know we're not.

It would have to depend on autoloads at compilation time.  As far as
I can tell, that's not extremely common.  It's quite more common
that things are `require`d and thus `load`ed at compilation time,
so if we block that, the Flymake compilation output becomes quite
useless in most cases, producing big single error in that first require.

Such things can and already do happen with processes that
have non-standard  load-paths mechanisms, such as one of mine.
The only load-path that the Flymake currently sees is the current
directory's.  I suppose extending that is possible (and it's been in my
plans). It's also possibly another "hazard", though one incurred in
consciously by the user,  whom we may warn via the usual "unsafe
local variables" machinery.

Jo=C3=A3o




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 18:47:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 13:47:09 2020
Received: from localhost ([127.0.0.1]:43153 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqhG1-0001q0-DY
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 13:47:09 -0500
Received: from mail200c50.megamailservers.eu ([91.136.10.210]:46396
 helo=mail193c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1kqhFw-0001pn-Bp
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 13:47:08 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1608403623;
 bh=6yH/77b5r8un8FFgUxZ7hpZC2k+a0WNZtfDAE8wM4Cc=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=lMm19z10l/Yd+JbzaaSGKjOiEszPTu415J77lNsHzxPCoKAFy6bWaYEnjwOF1AfWE
 +UcaQqvaO4COwEsdJ8ffglSUF+NQf7lY5GnOBUfI6DaseV/O2br3I3+voIso5IJyK4
 HqtV/DjXLmMafB9aHwYfXW1DvftCM50BlnebyyNY=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-064ae655.032-75-73746f71.bbcust.telenor.se
 [85.230.74.6]) (authenticated bits=0)
 by mail193c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BJIl0Uq009124; 
 Sat, 19 Dec 2020 18:47:02 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <jwvblepoeuq.fsf-monnier+emacs@HIDDEN>
Date: Sat, 19 Dec 2020 19:46:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <239166D0-63F2-48CF-AC26-B306B99419BC@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
 <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
 <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
 <jwvblepoeuq.fsf-monnier+emacs@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A782F18.5FDE4AA7.0019, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=TYHoSiYh c=1 sm=1 tr=0 a=Ni+dBsiEfW2GqKMPYZim9A==:117
 a=Ni+dBsiEfW2GqKMPYZim9A==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=iRZporoAAAAA:8 a=9D5SvJBBrBtOuh2ikD8A:9 a=CjuIK1q_8ugA:10
 a=NOBgFS-JBQ2l-kSd6-zu:22
X-Origin-Country: SE
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Philipp Stephani <p.stephani2@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

19 dec. 2020 kl. 19.11 skrev Stefan Monnier <monnier@HIDDEN>:

> I must say I don't know what's being discussed here.
> What autoloads?  Why do we care?

If a user looks at elisp code that depends on autoloads and the checker =
process cannot load those for reasons of sandbox policy or whatnot, =
there will be false positives about missing functions. This is fine if =
we are phasing out autoloads but as far as I know we're not.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 18:19:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 13:19:10 2020
Received: from localhost ([127.0.0.1]:43129 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqgov-00018n-Ed
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 13:19:10 -0500
Received: from mail-ot1-f53.google.com ([209.85.210.53]:43260)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kqgos-00018F-39
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 13:19:08 -0500
Received: by mail-ot1-f53.google.com with SMTP id q25so5144883otn.10
 for <45198 <at> debbugs.gnu.org>; Sat, 19 Dec 2020 10:19:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=UO+uHMzdtVCuhaWgbdTCxeeCbKdJ5CVPUAN0TpANr3s=;
 b=M1MAyUrmQbiN8cXCw49fsR9sb3st7nRvSQUNDkELVt5a9d+umt9LrJxwmXU+qWZl+Z
 iJONl/EUE35P64Cj5kfAH25VRKQILSG8DfF5w+3M8ANS7QFXElzLIy0LGlNViUk8xIei
 zPqHGCPSMjM//5R1nspj5fNVGklxFTwbSw28Sh1Uoro13aeVSQppaZXmg7zWxgiWYZhg
 mJaxWZW2pKHdyXzfUuDOO+iVmDKF9OviwXLDo7ox0whQn70syREQdpFNKcVBsFdIhrzB
 hnuCwQ4xZ3dinhvPLzHbjW5/Rt2gXI5tZwOtTe5OiPqm/yUcQNHwNyBgJcEbFC95TXkJ
 xrZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=UO+uHMzdtVCuhaWgbdTCxeeCbKdJ5CVPUAN0TpANr3s=;
 b=OUVgBJatZB0n61KiWgatYCe2SWhC82/RMuz8BgUBluRLddgFRi6sKppFHxzmXgFYGc
 z6sQSPhukCnFzHts8FW3/90FW9YcO/bkZ2KOv73DBiZXN5Ks14hLWebs69YLc/sES1JV
 5bMRxUt7xMiwkFs5VglclT7gcbTK/iCdbBm1IWkddw1kRaLu2L2UXiAI5ZyKKpPz8ino
 F9I9bBBitQN784fKudyfJ073dQy5UnZP/xo/1A+bDNc8LjxZLwjcgVoDpr+jbAZ4KrtY
 XXgJVfMw6yGP73LnqHMAwc3zQapq4AyK/lSR5EO8Qi6rYw03CEaTEumoPL6nYSlzkcQv
 gA+w==
X-Gm-Message-State: AOAM530/2Ow0BukvPO0v9uJJMLYfC8FC3Lxm3Y9QnCWtjazxgOKi0c3S
 3rG5LrsTjYpM068nqgbD7Grpm++WAer9kl8cn+0=
X-Google-Smtp-Source: ABdhPJxThOUH47ZplwyOAd2EaCQalVqgGe/91SaetkFO6b+aCawHG1VCsn9JbOcoMct39a7/MeFHQnqeGgXS1cLeP3w=
X-Received: by 2002:a9d:72c4:: with SMTP id d4mr7076971otk.149.1608401940105; 
 Sat, 19 Dec 2020 10:19:00 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
 <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
In-Reply-To: <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 19 Dec 2020 19:18:48 +0100
Message-ID: <CAArVCkSiTR6UBT3AcKYOe3Yr8TgizjVBOobF_PDv0JNUySj2CA@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/mixed; boundary="0000000000004c40a805b6d54284"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--0000000000004c40a805b6d54284
Content-Type: text/plain; charset="UTF-8"

Am Mo., 14. Dez. 2020 um 12:05 Uhr schrieb Philipp Stephani
<p.stephani2@HIDDEN>:
>
> > >> - This will need someone else doing the implementation.
> > > Looks like we already have a volunteer for macOS.
> > > For Linux, this shouldn't be that difficult either. The sandbox needs
> > > to install a mount namespace that only allows read access to Emacs's
> > > installation directory plus any input file and write access to known
> > > output files, and enable syscall filters that forbid everything except
> > > a list of known-safe syscalls (especially exec). I can take a stab at
> > > that, but I can't promise anything ;-)
> >
> > Looking forward to it.
> >
>
> I've looked into this, and what I'd suggest for now is:
> 1. Add a --seccomp=FILE command-line option that loads seccomp filters
> from FILE and applies them directly after startup (first thing in
> main). Why do this in Emacs? Because that's the easiest way to prevent
> execve. When installing a seccomp filter in a separate process, execve
> needs to be allowed because otherwise there'd be no way to execute the
> Emacs binary. While there are workarounds (ptrace, LD_PRELOAD), it's
> easiest to install the seccomp filter directly in the Emacs process.

I've attached a patch for this.

--0000000000004c40a805b6d54284
Content-Type: text/x-patch; charset="US-ASCII"; 
	name="0001-Add-support-for-seccomp-command-line-option.patch"
Content-Disposition: attachment; 
	filename="0001-Add-support-for-seccomp-command-line-option.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_kiw0xspy0>
X-Attachment-Id: f_kiw0xspy0

RnJvbSA4MGZjMGFiOTJlMWYwMjVhOGE0MTA0N2Q3OTA5YmU2YTk3ZjViMDlhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh
dGU6IE1vbiwgMTQgRGVjIDIwMjAgMjE6MjU6MTEgKzAxMDAKU3ViamVjdDogW1BBVENIXSBBZGQg
c3VwcG9ydCBmb3IgLS1zZWNjb21wIGNvbW1hbmQtbGluZSBvcHRpb24uCgpXaGVuIHBhc3Npbmcg
dGhpcyBvcHRpb24gb24gR05VL0xpbnV4LCBFbWFjcyBpbnN0YWxscyBhIFNlY3VyZQpDb21wdXRp
bmcga2VybmVsIHN5c3RlbSBjYWxsIGZpbHRlci4gIFNlZSBCdWcjNDUxOTguCgoqIGNvbmZpZ3Vy
ZS5hYzogQ2hlY2sgZm9yIHNlY2NvbXAgaGVhZGVyLgoKKiBzcmMvZW1hY3MuYyAodXNhZ2VfbWVz
c2FnZSk6IERvY3VtZW50IC0tc2VjY29tcCBvcHRpb24uCihlbWFjc19zZWNjb21wKTogTmV3IHdy
YXBwZXIgZm9yICdzZWNjb21wJyBzeXNjYWxsLgoobG9hZF9zZWNjb21wLCBtYXliZV9sb2FkX3Nl
Y2NvbXAsIHJlYWRfZnVsbCk6IE5ldyBoZWxwZXIgZnVuY3Rpb25zLgoobWFpbik6IFBvdGVudGlh
bGx5IGxvYWQgc2VjY29tcCBmaWx0ZXJzIGR1cmluZyBzdGFydHVwLgooc3RhbmRhcmRfYXJncyk6
IEFkZCAtLXNlY2NvbXAgb3B0aW9uLgoKKiBsaXNwL3N0YXJ0dXAuZWwgKGNvbW1hbmQtbGluZSk6
IERldGVjdCBhbmQgaWdub3JlIC0tc2VjY29tcCBvcHRpb24uCgoqIHRlc3Qvc3JjL2VtYWNzLXRl
c3RzLmVsIChlbWFjcy10ZXN0cy9zZWNjb21wL2Fic2VudC1maWxlKQooZW1hY3MtdGVzdHMvc2Vj
Y29tcC9lbXB0eS1maWxlKQooZW1hY3MtdGVzdHMvc2VjY29tcC9pbnZhbGlkLWZpbGUtc2l6ZSk6
IE5ldyB1bml0IHRlc3RzLgooZW1hY3MtdGVzdHMtLXdpdGgtdGVtcC1maWxlKTogTmV3IGhlbHBl
ciBtYWNyby4KCiogZXRjL05FV1M6IERvY3VtZW50IG5ldyAtLXNlY2NvbXAgb3B0aW9uLgotLS0K
IGNvbmZpZ3VyZS5hYyAgICAgICAgICAgIHwgICAyICsKIGV0Yy9ORVdTICAgICAgICAgICAgICAg
IHwgIDEwICsrKwogbGlzcC9zdGFydHVwLmVsICAgICAgICAgfCAgIDQgKy0KIHNyYy9lbWFjcy5j
ICAgICAgICAgICAgIHwgMTY4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
Ky0KIHRlc3Qvc3JjL2VtYWNzLXRlc3RzLmVsIHwgIDg2ICsrKysrKysrKysrKysrKysrKysrCiA1
IGZpbGVzIGNoYW5nZWQsIDI2NyBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygtKQogY3JlYXRl
IG1vZGUgMTAwNjQ0IHRlc3Qvc3JjL2VtYWNzLXRlc3RzLmVsCgpkaWZmIC0tZ2l0IGEvY29uZmln
dXJlLmFjIGIvY29uZmlndXJlLmFjCmluZGV4IDg4OGI0MTUxNDguLjA4N2RkNjdlMTggMTAwNjQ0
Ci0tLSBhL2NvbmZpZ3VyZS5hYworKysgYi9jb25maWd1cmUuYWMKQEAgLTQxODQsNiArNDE4NCw4
IEBAIEFDX0RFRlVOCiBBQ19TVUJTVChbQkxFU1NNQUlMX1RBUkdFVF0pCiBBQ19TVUJTVChbTElC
U19NQUlMXSkKIAorQUNfQ0hFQ0tfSEVBREVSUyhbbGludXgvc2VjY29tcC5oXSkKKwogT0xEX0xJ
QlM9JExJQlMKIExJQlM9IiRMSUJfUFRIUkVBRCAkTElCX01BVEggJExJQlMiCiBBQ19DSEVDS19G
VU5DUyhhY2NlcHQ0IGZjaGRpciBnZXRob3N0bmFtZSBcCmRpZmYgLS1naXQgYS9ldGMvTkVXUyBi
L2V0Yy9ORVdTCmluZGV4IDRhOGU3MGU2YTYuLmJkMjU1ZmFjYTQgMTAwNjQ0Ci0tLSBhL2V0Yy9O
RVdTCisrKyBiL2V0Yy9ORVdTCkBAIC04Miw2ICs4MiwxNiBAQCBsYWNrcyB0aGUgdGVybWluZm8g
ZGF0YWJhc2UsIHlvdSBjYW4gaW5zdHJ1Y3QgRW1hY3MgdG8gc3VwcG9ydCAyNC1iaXQKIHRydWUg
Y29sb3IgYnkgc2V0dGluZyAnQ09MT1JURVJNPXRydWVjb2xvcicgaW4gdGhlIGVudmlyb25tZW50
LiAgVGhpcyBpcwogdXNlZnVsIG9uIHN5c3RlbXMgc3VjaCBhcyBGcmVlQlNEIHdoaWNoIHNoaXBz
IG9ubHkgd2l0aCAiZXRjL3Rlcm1jYXAiLgogCisqKiBPbiBHTlUvTGludXggc3lzdGVtcywgRW1h
Y3Mgbm93IHN1cHBvcnRzIGxvYWRpbmcgYSBTZWN1cmUgQ29tcHV0aW5nCitmaWx0ZXIuICBUbyB1
c2UgdGhpcywgeW91IGNhbiBwYXNzIGEgLS1zZWNjb21wPUZJTEUgY29tbWFuZC1saW5lCitvcHRp
b24gdG8gRW1hY3MuICBGSUxFIG11c3QgbmFtZSBhIGJpbmFyeSBmaWxlIGNvbnRhaW5pbmcgYW4g
YXJyYXkgb2YKKydzdHJ1Y3Qgc29ja19maWx0ZXInIHN0cnVjdHVyZXMuICBFbWFjcyB3aWxsIHRo
ZW4gaW5zdGFsbCB0aGF0IGxpc3Qgb2YKK1NlY3VyZSBDb21wdXRpbmcgZmlsdGVycyBpbnRvIGl0
cyBvd24gcHJvY2VzcyBlYXJseSBkdXJpbmcgdGhlIHN0YXJ0dXAKK3Byb2Nlc3MuICBZb3UgY2Fu
IHVzZSB0aGlzIGZ1bmN0aW9uYWxpdHkgdG8gcHV0IGFuIEVtYWNzIHByb2Nlc3MgaW4gYQorc2Fu
ZGJveCB0byBhdm9pZCBzZWN1cml0eSBpc3N1ZXMgd2hlbiBleGVjdXRpbmcgdW50cnVzdGVkIGNv
ZGUuICBTZWUKK3RoZSBtYW51YWwgcGFnZSBmb3IgJ3NlY2NvbXAnIGZvciBkZXRhaWxzIGFib3V0
IFNlY3VyZSBDb21wdXRpbmcKK2ZpbHRlcnMuCisKIAwKICogQ2hhbmdlcyBpbiBFbWFjcyAyOC4x
CiAKZGlmZiAtLWdpdCBhL2xpc3Avc3RhcnR1cC5lbCBiL2xpc3Avc3RhcnR1cC5lbAppbmRleCBi
MTEyOGY2ZDAyLi45YjEzNDZlNDQ4IDEwMDY0NAotLS0gYS9saXNwL3N0YXJ0dXAuZWwKKysrIGIv
bGlzcC9zdGFydHVwLmVsCkBAIC0xMDk0LDcgKzEwOTQsNyBAQCBjb21tYW5kLWxpbmUKICAgICAg
ICAgICAgICAgICAgICAgICAgICAoIi0tbm8teC1yZXNvdXJjZXMiKSAoIi0tZGVidWctaW5pdCIp
CiAgICAgICAgICAgICAgICAgICAgICAgICAgKCItLXVzZXIiKSAoIi0taWNvbmljIikgKCItLWlj
b24tdHlwZSIpICgiLS1xdWljayIpCiAJCQkgKCItLW5vLWJsaW5raW5nLWN1cnNvciIpICgiLS1i
YXNpYy1kaXNwbGF5IikKLSAgICAgICAgICAgICAgICAgICAgICAgICAoIi0tZHVtcC1maWxlIikg
KCItLXRlbWFjcyIpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAoIi0tZHVtcC1maWxlIikg
KCItLXRlbWFjcyIpICgiLS1zZWNjb21wIikpKQogICAgICAgICAgICAgIChhcmdpIChwb3AgYXJn
cykpCiAgICAgICAgICAgICAgKG9yaWctYXJnaSBhcmdpKQogICAgICAgICAgICAgIGFyZ3ZhbCkK
QEAgLTExNDYsNyArMTE0Niw3IEBAIGNvbW1hbmQtbGluZQogCSAgKHB1c2ggJyh2aXNpYmlsaXR5
IC4gaWNvbikgaW5pdGlhbC1mcmFtZS1hbGlzdCkpCiAJICgobWVtYmVyIGFyZ2kgJygiLW5iYyIg
Ii1uby1ibGlua2luZy1jdXJzb3IiKSkKIAkgIChzZXRxIG5vLWJsaW5raW5nLWN1cnNvciB0KSkK
LSAgICAgICAgICgobWVtYmVyIGFyZ2kgJygiLWR1bXAtZmlsZSIgIi10ZW1hY3MiKSkgIDsgSGFu
ZGxlZCBpbiBDCisgICAgICAgICAoKG1lbWJlciBhcmdpICcoIi1kdW1wLWZpbGUiICItdGVtYWNz
IiAiLXNlY2NvbXAiKSkgIDsgSGFuZGxlZCBpbiBDCiAgICAgICAgICAgKG9yIGFyZ3ZhbCAocG9w
IGFyZ3MpKQogICAgICAgICAgIChzZXRxIGFyZ3ZhbCBuaWwpKQogCSA7OyBQdXNoIHRoZSBwb3Bw
ZWQgYXJnIGJhY2sgb24gdGhlIGxpc3Qgb2YgYXJndW1lbnRzLgpkaWZmIC0tZ2l0IGEvc3JjL2Vt
YWNzLmMgYi9zcmMvZW1hY3MuYwppbmRleCAyYTMyMDgzYmExLi4wYTkzOWZjOTAxIDEwMDY0NAot
LS0gYS9zcmMvZW1hY3MuYworKysgYi9zcmMvZW1hY3MuYwpAQCAtNjEsNiArNjEsMTMgQEAgI2Rl
ZmluZSBNQUlOX1BST0dSQU0KICMgaW5jbHVkZSA8c3lzL3NvY2tldC5oPgogI2VuZGlmCiAKKyNp
ZmRlZiBIQVZFX0xJTlVYX1NFQ0NPTVBfSAorIyBpbmNsdWRlIDxsaW51eC9zZWNjb21wLmg+Cisj
IGluY2x1ZGUgPGxpbnV4L2ZpbHRlci5oPgorIyBpbmNsdWRlIDxzeXMvcHJjdGwuaD4KKyMgaW5j
bHVkZSA8c3lzL3N5c2NhbGwuaD4KKyNlbmRpZgorCiAjaWZkZWYgSEFWRV9XSU5ET1dfU1lTVEVN
CiAjaW5jbHVkZSBURVJNX0hFQURFUgogI2VuZGlmIC8qIEhBVkVfV0lORE9XX1NZU1RFTSAqLwpA
QCAtMjM5LDYgKzI0NiwxMSBAQCAjZGVmaW5lIE1BSU5fUFJPR1JBTQogICAgICJcCiAtLWR1bXAt
ZmlsZSBGSUxFICAgICAgICAgICAgcmVhZCBkdW1wZWQgc3RhdGUgZnJvbSBGSUxFXG5cCiAiLAor
I2VuZGlmCisjaWZkZWYgSEFWRV9MSU5VWF9TRUNDT01QX0gKKyAgICAiXAorLS1zYW5kYm94PUZJ
TEUgICAgICAgICAgICAgIHJlYWQgU2VjY29tcCBCUEYgZmlsdGVyIGZyb20gRklMRVxuXAorIgog
I2VuZGlmCiAgICAgIlwKIC0tbm8tYnVpbGQtZGV0YWlscyAgICAgICAgICBkbyBub3QgYWRkIGJ1
aWxkIGRldGFpbHMgc3VjaCBhcyB0aW1lIHN0YW1wc1xuXApAQCAtOTM3LDYgKzk0OSwxNTAgQEAg
bG9hZF9wZHVtcCAoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogfQogI2VuZGlmIC8qIEhBVkVfUERV
TVBFUiAqLwogCisjaWZkZWYgSEFWRV9MSU5VWF9TRUNDT01QX0gKKworLyogV3JhcHBlciBmdW5j
dGlvbiBmb3IgdGhlIGBzZWNjb21wJyBzeXN0ZW0gY2FsbCBvbiBHTlUvTGludXguICBUaGlzIHN5
c3RlbQorICAgY2FsbCB1c3VhbGx5IGRvZXNuJ3QgaGF2ZSBhIHdyYXBwZXIgZnVuY3Rpb24uICBT
ZWUgdGhlIG1hbnVhbCBwYWdlIG9mCisgICBgc2VjY29tcCcgZm9yIHRoZSBzaWduYXR1cmUuICAq
LworCitzdGF0aWMgaW50CitlbWFjc19zZWNjb21wICh1bnNpZ25lZCBpbnQgb3BlcmF0aW9uLCB1
bnNpZ25lZCBpbnQgZmxhZ3MsIHZvaWQgKmFyZ3MpCit7CisjaWZkZWYgU1lTX3NlY2NvbXAKKyAg
cmV0dXJuIHN5c2NhbGwgKFNZU19zZWNjb21wLCBvcGVyYXRpb24sIGZsYWdzLCBhcmdzKTsKKyNl
bHNlCisgIGVycm5vID0gRU5PU1lTOworICByZXR1cm4gLTE7CisjZW5kaWYKK30KKworLyogUmVh
ZCBleGFjdGx5IFNJWkUgYnl0ZXMgaW50byBCVUZGRVIuICBSZXR1cm4gZmFsc2Ugb24gc2hvcnQg
cmVhZC4gICovCisKK3N0YXRpYyBib29sCityZWFkX2Z1bGwgKGludCBmZCwgdm9pZCAqYnVmZmVy
LCBzaXplX3Qgc2l6ZSkKK3sKKyAgaWYgKFNTSVpFX01BWCA8IHNpemUpCisgICAgeworICAgICAg
ZXJybm8gPSBFRkJJRzsKKyAgICAgIHJldHVybiBmYWxzZTsKKyAgICB9CisgIGNoYXIgKnB0ciA9
IGJ1ZmZlcjsKKyAgd2hpbGUgKHNpemUgIT0gMCkKKyAgICB7CisgICAgICAvKiBXZSBjYW4ndCB1
c2UgYGVtYWNzX3JlYWQnIHlldCBiZWNhdXNlIHF1aXR0aW5nIGRvZXNuJ3Qgd29yayBoZXJlCisg
ICAgICAgICB5ZXQuICAqLworICAgICAgc3NpemVfdCByZXQgPSBURU1QX0ZBSUxVUkVfUkVUUlkg
KHJlYWQgKGZkLCBwdHIsIHNpemUpKTsKKyAgICAgIGlmIChyZXQgPCAwKQorICAgICAgICByZXR1
cm4gZmFsc2U7CisgICAgICBpZiAocmV0ID09IDApCisgICAgICAgIGJyZWFrOyAgLyogQXZvaWQg
aW5maW5pdGUgbG9vcCBvbiBlbmNvdW50ZXJpbmcgRU9GLiAgKi8KKyAgICAgIGVhc3NlcnQgKHJl
dCA8PSBzaXplKTsKKyAgICAgIHNpemUgLT0gcmV0OworICAgICAgcHRyICs9IHJldDsKKyAgICB9
CisgIGlmIChzaXplICE9IDApCisgICAgZXJybm8gPSBFTk9EQVRBOworICByZXR1cm4gc2l6ZSA9
PSAwOworfQorCisvKiBBdHRlbXB0IHRvIGxvYWQgU2VjdXJlIENvbXB1dGluZyBmaWx0ZXJzIGZy
b20gRklMRS4gIFJldHVybiBmYWxzZSBpZiB0aGF0CisgICBkb2Vzbid0IHdvcmsgZm9yIHNvbWUg
cmVhc29uLiAgKi8KKworc3RhdGljIGJvb2wKK2xvYWRfc2VjY29tcCAoY29uc3QgY2hhciAqZmls
ZSkKK3sKKyAgYm9vbCBzdWNjZXNzID0gZmFsc2U7CisgIHN0cnVjdCBzb2NrX2Zwcm9nIHByb2dy
YW0gPSB7MCwgTlVMTH07CisgIC8qIFdlIGNhbid0IHVzZSBgZW1hY3Nfb3BlbicgeWV0IGJlY2F1
c2UgcXVpdHRpbmcgZG9lc24ndCB3b3JrIGhlcmUgeWV0LiAgKi8KKyAgaW50IGZkID0gVEVNUF9G
QUlMVVJFX1JFVFJZIChvcGVuIChmaWxlLCBPX1JET05MWSB8IE9fQklOQVJZIHwgT19DTE9FWEVD
KSk7CisgIGlmIChmZCA8IDApCisgICAgeworICAgICAgZW1hY3NfcGVycm9yICgib3BlbiIpOwor
ICAgICAgZ290byBvdXQ7CisgICAgfQorICBzdHJ1Y3Qgc3RhdCBzdGF0OworICBpZiAoZnN0YXQg
KGZkLCAmc3RhdCkgPCAwKQorICAgIHsKKyAgICAgIGVtYWNzX3BlcnJvciAoImZzdGF0Iik7Cisg
ICAgICBnb3RvIG91dDsKKyAgICB9CisgIGlmIChzdGF0LnN0X3NpemUgPD0gMCB8fCBTSVpFX01B
WCA8IHN0YXQuc3Rfc2l6ZQorICAgICAgfHwgKHNpemVfdCkgc3RhdC5zdF9zaXplICUgc2l6ZW9m
ICpwcm9ncmFtLmZpbHRlciAhPSAwKQorICAgIHsKKyAgICAgIGZwcmludGYgKHN0ZGVyciwgInNl
Y2NvbXAgZmlsdGVyICVzIGhhcyBpbnZhbGlkIHNpemUgJWpkXG4iLCBmaWxlLAorICAgICAgICAg
ICAgICAgKGludG1heF90KSBzdGF0LnN0X3NpemUpOworICAgICAgZ290byBvdXQ7CisgICAgfQor
ICBzaXplX3Qgc2l6ZSA9IHN0YXQuc3Rfc2l6ZTsKKyAgc2l6ZV90IGNvdW50ID0gc2l6ZSAvIHNp
emVvZiAqcHJvZ3JhbS5maWx0ZXI7CisgIGVhc3NlcnQgKDAgPCBzaXplICYmIDAgPCBjb3VudCk7
CisgIGlmIChVU0hSVF9NQVggPCBjb3VudCkKKyAgICB7CisgICAgICBmcHJpbnRmIChzdGRlcnIs
ICJzZWNjb21wIGZpbHRlciAlcyBpcyB0b28gYmlnIiwgZmlsZSk7CisgICAgICBnb3RvIG91dDsK
KyAgICB9CisgIHByb2dyYW0ubGVuID0gY291bnQ7CisgIHByb2dyYW0uZmlsdGVyID0gbWFsbG9j
IChzaXplKTsKKyAgaWYgKHByb2dyYW0uZmlsdGVyID09IE5VTEwpCisgICAgeworICAgICAgZW1h
Y3NfcGVycm9yICgibWFsbG9jIik7CisgICAgICBnb3RvIG91dDsKKyAgICB9CisgIGlmICghcmVh
ZF9mdWxsIChmZCwgcHJvZ3JhbS5maWx0ZXIsIHNpemUpKQorICAgIHsKKyAgICAgIGVtYWNzX3Bl
cnJvciAoInJlYWQiKTsKKyAgICAgIGdvdG8gb3V0OworICAgIH0KKyAgaWYgKGNsb3NlIChmZCkg
IT0gMCkKKyAgICBlbWFjc19wZXJyb3IgKCJjbG9zZSIpOyAgLyogbm90IGNyaXRpY2FsICovCisg
IGZkID0gLTE7CisKKyAgLyogU2VlIG1hbiBwYWdlIG9mIGBzZWNjb21wJyB3aHkgdGhpcyBpcyBu
ZWNlc3NhcnkuICBOb3RlIHRoYXQgd2UKKyAgICAgaW50ZW50aW9uYWxseSBkb24ndCBjaGVjayB0
aGUgcmV0dXJuIHZhbHVlOiBhIHBhcmVudCBwcm9jZXNzIG1pZ2h0IGhhdmUKKyAgICAgbWFkZSB0
aGlzIGNhbGwgYmVmb3JlLCBpbiB3aGljaCBjYXNlIGl0IHdvdWxkIGZhaWw7IG9yLCBpZiBlbmFi
bGluZworICAgICBwcml2aWxlZ2UtcmVzdHJpY3RpbmcgbW9kZSBmYWlscywgdGhlIGBzZWNjb21w
JyBzeXNjYWxsIHdpbGwgZmFpbAorICAgICBhbnl3YXkuICAqLworICBwcmN0bCAoUFJfU0VUX05P
X05FV19QUklWUywgMSwgMCwgMCwgMCk7CisgIC8qIEluc3RhbGwgdGhlIGZpbHRlci4gIE1ha2Ug
c3VyZSB0aGF0IHBvdGVudGlhbCBvdGhlciB0aHJlYWRzIGNhbid0IGVzY2FwZQorICAgICBpdC4g
ICovCisgIGlmIChlbWFjc19zZWNjb21wIChTRUNDT01QX1NFVF9NT0RFX0ZJTFRFUiwgU0VDQ09N
UF9GSUxURVJfRkxBR19UU1lOQywKKyAgICAgICAgICAgICAgICAgICAgICZwcm9ncmFtKQorICAg
ICAgIT0gMCkKKyAgICB7CisgICAgICBlbWFjc19wZXJyb3IgKCJzZWNjb21wIik7CisgICAgICBn
b3RvIG91dDsKKyAgICB9CisgIHN1Y2Nlc3MgPSB0cnVlOworCisgb3V0OgorICBmcmVlIChwcm9n
cmFtLmZpbHRlcik7CisgIGNsb3NlIChmZCk7CisgIHJldHVybiBzdWNjZXNzOworfQorCisvKiBM
b2FkIFNlY3VyZSBDb21wdXRpbmcgZmlsdGVyIGZyb20gZmlsZSBzcGVjaWZpZWQgd2l0aCB0aGUg
LS1zZWNjb21wIG9wdGlvbi4KKyAgIEV4aXQgaWYgdGhhdCBmYWlscy4gICovCisKK3N0YXRpYyB2
b2lkCittYXliZV9sb2FkX3NlY2NvbXAgKGludCBhcmdjLCBjaGFyICoqYXJndikKK3sKKyAgaW50
IHNraXBfYXJncyA9IDA7CisgIGNoYXIgKmZpbGUgPSBOVUxMOworICB3aGlsZSAoc2tpcF9hcmdz
IDwgYXJnYyAtIDEpCisgICAgeworICAgICAgaWYgKGFyZ21hdGNoIChhcmd2LCBhcmdjLCAiLXNl
Y2NvbXAiLCAiLS1zZWNjb21wIiwgOSwgJmZpbGUsICZza2lwX2FyZ3MpCisgICAgICAgICAgfHwg
YXJnbWF0Y2ggKGFyZ3YsIGFyZ2MsICItLSIsIE5VTEwsIDIsIE5VTEwsICZza2lwX2FyZ3MpKQor
ICAgICAgICBicmVhazsKKyAgICAgICsrc2tpcF9hcmdzOworICAgIH0KKyAgaWYgKGZpbGUgPT0g
TlVMTCkKKyAgICByZXR1cm47CisgIGlmICghbG9hZF9zZWNjb21wIChmaWxlKSkKKyAgICBmYXRh
bCAoImNhbm5vdCBlbmFibGUgc2VjY29tcCBmaWx0ZXIgZnJvbSAlcyIsIGZpbGUpOworfQorCisj
ZW5kaWYgIC8qIEhBVkVfTElOVVhfU0VDQ09NUF9IICovCisKIGludAogbWFpbiAoaW50IGFyZ2Ms
IGNoYXIgKiphcmd2KQogewpAQCAtOTQ0LDYgKzExMDAsMTMgQEAgbWFpbiAoaW50IGFyZ2MsIGNo
YXIgKiphcmd2KQogICAgICBmb3IgcG9pbnRlcnMuICAqLwogICB2b2lkICpzdGFja19ib3R0b21f
dmFyaWFibGU7CiAKKyAgLyogRmlyc3QsIGNoZWNrIHdoZXRoZXIgd2Ugc2hvdWxkIGFwcGx5IGEg
c2VjY29tcCBmaWx0ZXIuICBUaGlzIHNob3VsZCBjb21lIGF0CisgICAgIHRoZSB2ZXJ5IGJlZ2lu
bmluZyB0byBhbGxvdyB0aGUgZmlsdGVyIHRvIHByb3RlY3QgdGhlIGluaXRpYWxpemF0aW9uCisg
ICAgIHBoYXNlLiAgKi8KKyNpZmRlZiBIQVZFX0xJTlVYX1NFQ0NPTVBfSAorICBtYXliZV9sb2Fk
X3NlY2NvbXAgKGFyZ2MsIGFyZ3YpOworI2VuZGlmCisKICAgYm9vbCBub19sb2FkdXAgPSBmYWxz
ZTsKICAgY2hhciAqanVuayA9IDA7CiAgIGNoYXIgKmRuYW1lX2FyZyA9IDA7CkBAIC0yMTM3LDEy
ICsyMzAwLDE1IEBAIG1haW4gKGludCBhcmdjLCBjaGFyICoqYXJndikKICAgeyAiLWNvbG9yIiwg
Ii0tY29sb3IiLCA1LCAwfSwKICAgeyAiLW5vLXNwbGFzaCIsICItLW5vLXNwbGFzaCIsIDMsIDAg
fSwKICAgeyAiLW5vLWRlc2t0b3AiLCAiLS1uby1kZXNrdG9wIiwgMywgMCB9LAotICAvKiBUaGUg
Zm9sbG93aW5nIHR3byBtdXN0IGJlIGp1c3QgYWJvdmUgdGhlIGZpbGUtbmFtZSBhcmdzLCB0byBn
ZXQKKyAgLyogVGhlIGZvbGxvd2luZyB0aHJlZSBtdXN0IGJlIGp1c3QgYWJvdmUgdGhlIGZpbGUt
bmFtZSBhcmdzLCB0byBnZXQKICAgICAgdGhlbSBvdXQgb2Ygb3VyIHdheSwgYnV0IHdpdGhvdXQg
bWl4aW5nIHRoZW0gd2l0aCBmaWxlIG5hbWVzLiAgKi8KICAgeyAiLXRlbWFjcyIsICItLXRlbWFj
cyIsIDEsIDEgfSwKICNpZmRlZiBIQVZFX1BEVU1QRVIKICAgeyAiLWR1bXAtZmlsZSIsICItLWR1
bXAtZmlsZSIsIDEsIDEgfSwKICNlbmRpZgorI2lmZGVmIEhBVkVfTElOVVhfU0VDQ09NUF9ICisg
IHsgIi1zZWNjb21wIiwgIi0tc2VjY29tcCIsIDEsIDEgfSwKKyNlbmRpZgogI2lmZGVmIEhBVkVf
TlMKICAgeyAiLU5TQXV0b0xhdW5jaCIsIDAsIDUsIDEgfSwKICAgeyAiLU5YQXV0b0xhdW5jaCIs
IDAsIDUsIDEgfSwKZGlmZiAtLWdpdCBhL3Rlc3Qvc3JjL2VtYWNzLXRlc3RzLmVsIGIvdGVzdC9z
cmMvZW1hY3MtdGVzdHMuZWwKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMDAwMC4u
Mjc5ZWNiMjEwYwotLS0gL2Rldi9udWxsCisrKyBiL3Rlc3Qvc3JjL2VtYWNzLXRlc3RzLmVsCkBA
IC0wLDAgKzEsODYgQEAKKzs7OyBlbWFjcy10ZXN0cy5lbCAtLS0gdW5pdCB0ZXN0cyBmb3IgZW1h
Y3MuYyAtKi0gbGV4aWNhbC1iaW5kaW5nOiB0OyAtKi0KKworOzsgQ29weXJpZ2h0IChDKSAyMDIw
ICBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKworOzsgVGhpcyBmaWxlIGlzIHBhcnQg
b2YgR05VIEVtYWNzLgorCis7OyBHTlUgRW1hY3MgaXMgZnJlZSBzb2Z0d2FyZTogeW91IGNhbiBy
ZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorOzsgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRo
ZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKzs7IHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb24sIGVpdGhlciB2ZXJzaW9uIDMgb2YgdGhlIExpY2Vuc2UsIG9y
Cis7OyAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLgorCis7OyBHTlUgRW1hY3Mg
aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKzs7IGJ1
dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5
IG9mCis7OyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP
U0UuICBTZWUgdGhlCis7OyBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRh
aWxzLgorCis7OyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZQorOzsgYWxvbmcgd2l0aCBHTlUgRW1hY3MuICBJZiBub3QsIHNl
ZSA8aHR0cHM6Ly93d3cuZ251Lm9yZy9saWNlbnNlcy8+LgorCis7OzsgQ29tbWVudGFyeToKKwor
OzsgVW5pdCB0ZXN0cyBmb3Igc3JjL2VtYWNzLmMuCisKKzs7OyBDb2RlOgorCisocmVxdWlyZSAn
Y2wtbGliKQorKHJlcXVpcmUgJ2VydCkKKworKGVydC1kZWZ0ZXN0IGVtYWNzLXRlc3RzL3NlY2Nv
bXAvYWJzZW50LWZpbGUgKCkKKyAgKGxldCAoKGVtYWNzIChleHBhbmQtZmlsZS1uYW1lIGludm9j
YXRpb24tbmFtZSBpbnZvY2F0aW9uLWRpcmVjdG9yeSkpCisgICAgICAgIChwcm9jZXNzLWVudmly
b25tZW50IG5pbCkpCisgICAgKHNraXAtdW5sZXNzIChmaWxlLWV4ZWN1dGFibGUtcCBlbWFjcykp
CisgICAgKHNob3VsZC1ub3QgKGZpbGUtZXhpc3RzLXAgIi9kb2VzLW5vdC1leGlzdC5icGYiKSkK
KyAgICAoc2hvdWxkLW5vdAorICAgICAoZXFsIChjYWxsLXByb2Nlc3MgZW1hY3MgbmlsIG5pbCBu
aWwKKyAgICAgICAgICAgICAgICAgICAgICAgICItLXF1aWNrIiAiLS1iYXRjaCIgIi0tc2VjY29t
cD0vZG9lcy1ub3QtZXhpc3QuYnBmIikKKyAgICAgICAgICAwKSkpKQorCisoY2wtZGVmbWFjcm8g
ZW1hY3MtdGVzdHMtLXdpdGgtdGVtcC1maWxlCisgICAgKHZhciAocHJlZml4ICZvcHRpb25hbCBz
dWZmaXggdGV4dCkgJnJlc3QgYm9keSkKKyAgIkV2YWx1YXRlIEJPRFkgd2hpbGUgYSBuZXcgdGVt
cG9yYXJ5IGZpbGUgZXhpc3RzLgorQmluZCBWQVIgdG8gdGhlIG5hbWUgb2YgdGhlIGZpbGUuICBQ
YXNzIFBSRUZJWCwgU1VGRklYLCBhbmQgVEVYVAordG8gYG1ha2UtdGVtcC1maWxlJywgd2hpY2gg
c2VlLiIKKyAgKGRlY2xhcmUgKGluZGVudCAyKSAoZGVidWcgKHN5bWJvbHAgKGZvcm0gZm9ybSBm
b3JtKSBib2R5KSkpCisgIChjbC1jaGVjay10eXBlIHZhciBzeW1ib2wpCisgIDs7IFVzZSBhbiB1
bmludGVybmVkIHN5bWJvbCBzbyB0aGF0IHRoZSBjb2RlIHN0aWxsIHdvcmtzIGlmIEJPRFkgY2hh
bmdlcyBWQVIuCisgIChsZXQgKChmaWxlbmFtZSAobWFrZS1zeW1ib2wgImZpbGVuYW1lIikpKQor
ICAgIGAobGV0ICgoLGZpbGVuYW1lIChtYWtlLXRlbXAtZmlsZSAscHJlZml4IG5pbCAsc3VmZml4
ICx0ZXh0KSkpCisgICAgICAgKHVud2luZC1wcm90ZWN0CisgICAgICAgICAgIChsZXQgKCgsdmFy
ICxmaWxlbmFtZSkpCisgICAgICAgICAgICAgLEBib2R5KQorICAgICAgICAgKGRlbGV0ZS1maWxl
ICxmaWxlbmFtZSkpKSkpCisKKyhlcnQtZGVmdGVzdCBlbWFjcy10ZXN0cy9zZWNjb21wL2VtcHR5
LWZpbGUgKCkKKyAgKGxldCAoKGVtYWNzIChleHBhbmQtZmlsZS1uYW1lIGludm9jYXRpb24tbmFt
ZSBpbnZvY2F0aW9uLWRpcmVjdG9yeSkpCisgICAgICAgIChwcm9jZXNzLWVudmlyb25tZW50IG5p
bCkpCisgICAgKHNraXAtdW5sZXNzIChmaWxlLWV4ZWN1dGFibGUtcCBlbWFjcykpCisgICAgKGVt
YWNzLXRlc3RzLS13aXRoLXRlbXAtZmlsZSBmaWx0ZXIgKCJzZWNjb21wLWludmFsaWQtIiAiLmJw
ZiIpCisgICAgICA7OyBUaGUgLS1zZWNjb21wIG9wdGlvbiBpcyBwcm9jZXNzZWQgZWFybHksIHdp
dGhvdXQgZmlsZW5hbWUgaGFuZGxlcnMuCisgICAgICA7OyBUaGVyZWZvcmUgcmVtb3RlIG9yIHF1
b3RlZCBmaWxlbmFtZXMgd291bGRuJ3Qgd29yay4KKyAgICAgIChzaG91bGQtbm90IChmaWxlLXJl
bW90ZS1wIGZpbHRlcikpCisgICAgICAoY2wtY2FsbGYgZmlsZS1uYW1lLXVucXVvdGUgZmlsdGVy
KQorICAgICAgOzsgQWNjb3JkaW5nIHRvIHRoZSBTZWNjb21wIG1hbiBwYWdlLCBhIGZpbHRlciBt
dXN0IGhhdmUgYXQgbGVhc3Qgb25lCisgICAgICA7OyBlbGVtZW50LCBzbyBFbWFjcyBzaG91bGQg
cmVqZWN0IGFuIGVtcHR5IGZpbGUuCisgICAgICAoc2hvdWxkLW5vdAorICAgICAgIChlcWwgKGNh
bGwtcHJvY2VzcyBlbWFjcyBuaWwgbmlsIG5pbAorICAgICAgICAgICAgICAgICAgICAgICAgICAi
LS1xdWljayIgIi0tYmF0Y2giIChjb25jYXQgIi0tc2VjY29tcD0iIGZpbHRlcikpCisgICAgICAg
ICAgICAwKSkpKSkKKworKGVydC1kZWZ0ZXN0IGVtYWNzLXRlc3RzL3NlY2NvbXAvaW52YWxpZC1m
aWxlLXNpemUgKCkKKyAgKGxldCAoKGVtYWNzIChleHBhbmQtZmlsZS1uYW1lIGludm9jYXRpb24t
bmFtZSBpbnZvY2F0aW9uLWRpcmVjdG9yeSkpCisgICAgICAgIChwcm9jZXNzLWVudmlyb25tZW50
IG5pbCkpCisgICAgKHNraXAtdW5sZXNzIChmaWxlLWV4ZWN1dGFibGUtcCBlbWFjcykpCisgICAg
KGVtYWNzLXRlc3RzLS13aXRoLXRlbXAtZmlsZSBmaWx0ZXIgKCJzZWNjb21wLWludmFsaWQtIiAi
LmJwZiIgIjEyMzQ1NiIpCisgICAgICA7OyBUaGUgLS1zZWNjb21wIG9wdGlvbiBpcyBwcm9jZXNz
ZWQgZWFybHksIHdpdGhvdXQgZmlsZW5hbWUgaGFuZGxlcnMuCisgICAgICA7OyBUaGVyZWZvcmUg
cmVtb3RlIG9yIHF1b3RlZCBmaWxlbmFtZXMgd291bGRuJ3Qgd29yay4KKyAgICAgIChzaG91bGQt
bm90IChmaWxlLXJlbW90ZS1wIGZpbHRlcikpCisgICAgICAoY2wtY2FsbGYgZmlsZS1uYW1lLXVu
cXVvdGUgZmlsdGVyKQorICAgICAgOzsgVGhlIFNlY2NvbXAgZmlsdGVyIGZpbGUgbXVzdCBoYXZl
IGEgZmlsZSBzaXplIHRoYXQncyBhIG11bHRpcGxlIG9mIHRoZQorICAgICAgOzsgc2l6ZSBvZiBz
dHJ1Y3Qgc29ja19maWx0ZXIsIHdoaWNoIGlzIDggb3IgMTYsIGJ1dCBuZXZlciA2LgorICAgICAg
KHNob3VsZC1ub3QKKyAgICAgICAoZXFsIChjYWxsLXByb2Nlc3MgZW1hY3MgbmlsIG5pbCBuaWwK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgIi0tcXVpY2siICItLWJhdGNoIiAoY29uY2F0ICIt
LXNlY2NvbXA9IiBmaWx0ZXIpKQorICAgICAgICAgICAgMCkpKSkpCisKKzs7OyBlbWFjcy10ZXN0
cy5lbCBlbmRzIGhlcmUKLS0gCjIuMjkuMi43MjkuZzQ1ZGFmODc3N2QtZ29vZwoK
--0000000000004c40a805b6d54284--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 18:12:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 13:12:07 2020
Received: from localhost ([127.0.0.1]:43113 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqgi7-0007Ii-9t
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 13:12:07 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29327)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kqgi4-0007IB-98
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 13:12:06 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0971F809A5;
 Sat, 19 Dec 2020 13:11:59 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7FA7380668;
 Sat, 19 Dec 2020 13:11:57 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1608401517;
 bh=pn3XQHTzzJAMfq4kW8xwVQbUyw64LIaMVfMsvROlauI=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=FQf6BajSU6AU2HyEppyDBGy38AL5ElOo+KYB5KuKqb/OZJfgNLOpixAhuc0qYrImx
 cKKvrLbmgsDGDu3NgTPx3O2QIl2IjsxYXPFYOXFX5Qvae0FrvPPvYlfWXOQeYmJmXX
 PFx9WU9ufpeBc9Dis+gPOHfDrx9I08g+iWucZd5Thu1je9XQuaeb32e9h+kVT7UbBJ
 l4uD6rfFQxE5+BJA5AXiM8Cc1mbnXl7/4fDChgyipKvKmVD5cBywAdCvEwd7qPKE3K
 hFBWLrSqqDlC1vswevTp75YiUXkZU14g9pRsAj7BHfHm66XKoZxR/6KkbxNjWH7MnQ
 BbMEKdVmckV5g==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2FD7B1202C2;
 Sat, 19 Dec 2020 13:11:57 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Mattias =?windows-1252?Q?Engdeg=E5rd?= <mattiase@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwvblepoeuq.fsf-monnier+emacs@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
 <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
 <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
Date: Sat, 19 Dec 2020 13:11:56 -0500
In-Reply-To: <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN> ("Mattias
 =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Sat, 19 Dec 2020 18:19:32
 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.074 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Philipp Stephani <p.stephani2@HIDDEN>,
 =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

[ I'm afraid I dropped out of the discussion, so I may lack some
  context.  ]

> What I meant is that there is no way of knowing whether an API is rubbish or
> not without having put it to use ourselves first (preferably in two or more
> ways), so let's not front-load the design. We know that this is true
> regardless of how good programmers we think we are. 
> Flymake would be a natural user, but it must cope with our own demands first.

IIUC the discussion surrounds mostly around restricting
file-reads, right?  I agree it'd be good to have a sandbox that
restricts file-reads, but we should think about how to design such
a thing, i.e. how to specify (and then enforce) which files can be read.

My experience with the GNU ELPA scripts using bwrap is that it might not
be easy: we definitely don't want to give read access to /etc, yet it
seems very likely that some files in /etc may be needed, even in very
mundane circumstances (e.g. /etc/alternatives or /etc/emacs or ...).
This gets quickly very OS-dependent (and doesn't depend just on
Windows-vs-GNU/Linux but varies also between distributions of
GNU/Linux).  If we stick to an "in-process" sandbox (i.e. you can't run
sub-processes) it makes this a bit simpler (you don't need to worry
about read access to /lib vs /lib64 and other such things), so maybe it
is manageable.  But I think the starting point would be to give read
access to everything that's under one of the directories mentioned in
`load-path`.

> There's a difference though: flycheck is installed by someone who wants to
> use it and is presumably ready for some setting-up. In contrast, we are
> aiming at an on-by-default zero-configuration Emacs feature, which means
> that the bar is higher. It's meant precisely for those who would not install
> and configure flycheck, so false positives may have effects opposite
> the intended.

Indeed, in order to enable flymake by default we're going to have to be
extra careful to try and make sure the user isn't smothered in warnings.
That probably means for example to keep flymake disabled when visiting
the init file.

>> I also think that packages shouldn't rely on autoloads from other
>> packages. I generally dislike autoloads and think they are overused.
>> They make programming unnecessarily brittle because they assume not
>> only that the load path is set up correctly, but also that the correct
>> loaddefs files are already loaded. Autoloads are probably fine for
>> interactive commands to avoid unnecessarily loading rarely-used
>> packages, but inter-package dependencies should just use 'require'.
> I don't necessarily disagree but it would be interesting to hear what Stefan
> thinks about it. Since it's somewhat of an opinionated tool after all, it's
> squarely within our remit to lay down policy...

I must say I don't know what's being discussed here.
What autoloads?  Why do we care?


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 17:19:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 12:19:40 2020
Received: from localhost ([127.0.0.1]:43061 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqftM-000601-7z
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 12:19:40 -0500
Received: from mail150c50.megamailservers.eu ([91.136.10.160]:60772
 helo=mail50c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1kqftJ-0005zr-M7
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 12:19:38 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1608398376;
 bh=6M8tWVZhzpVnVSylxpdH/SeYMk/8zz1Arrb6ucrN99c=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=RobZbhWnlOq2rVksBr9VpNrYzD87ZREYp4rCpINFRiT1kvlTgLGchZszs0ULdkXy+
 0xRUus/p6LyeK9D4zrtwvzBjDmrBzp5BWQHDoo4f0BPseETV40VvBSrZG+0qPN9G0A
 ny8qAo61QHo082HPHQ35P7dMQFj8S25xoys8Aol4=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-064ae655.032-75-73746f71.bbcust.telenor.se
 [85.230.74.6]) (authenticated bits=0)
 by mail50c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BJHJX2A003828; 
 Sat, 19 Dec 2020 17:19:34 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
Date: Sat, 19 Dec 2020 18:19:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
 <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A782F1D.5FDE3628.001D, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=EoysUhUA c=1 sm=1 tr=0 a=Ni+dBsiEfW2GqKMPYZim9A==:117
 a=Ni+dBsiEfW2GqKMPYZim9A==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=pGLkceISAAAA:8 a=pab_C4cjCCZU-3B4GMoA:9 a=CjuIK1q_8ugA:10
X-Origin-Country: SE
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

19 dec. 2020 kl. 16.08 skrev Philipp Stephani <p.stephani2@HIDDEN>:

> I'd say these two questions are somewhat independent of each other.
> Even with an internal-only interface, people will start to assume that
> reading arbitrary files works.
> I'm personally not a huge fan of such internal interfaces though. They
> are necessary in some cases, but a high-level UI framework like
> Flymake shouldn't need to use them. Besides, since Flymake is released
> as an external package, it should rather not use internal interfaces
> in the first place.

What I meant is that there is no way of knowing whether an API is =
rubbish or not without having put it to use ourselves first (preferably =
in two or more ways), so let's not front-load the design. We know that =
this is true regardless of how good programmers we think we are.=20
Flymake would be a natural user, but it must cope with our own demands =
first.

>> Thanks for the reference, and you may very well be right. A =
counterpoint is that since the facility would be enabled by default, a =
user met with complaints about perfectly fine code will immediately =
disable the checks and thus foil our plan to nudge his coding habits in =
a desirable direction.
>=20
> Maybe, though I wouldn't be so sure. Elisp compilation in Flycheck is
> enabled by default and presumably suffers from the same problems.
> There are also similar problems with other languages: for example,
> when I visit src/lisp.h and enable Flymake, I get 2287 errors, 154
> warnings, and 4002 notices (which is an actual problem since the huge
> number of overlays makes Emacs sluggish - probably Flymake should just
> stop after 20 diagnostics or so...). I totally agree that we need to
> keep the false positive rate low, but I wouldn't say that any nonzero
> rate would make Flymake useless.

There's a difference though: flycheck is installed by someone who wants =
to use it and is presumably ready for some setting-up. In contrast, we =
are aiming at an on-by-default zero-configuration Emacs feature, which =
means that the bar is higher. It's meant precisely for those who would =
not install and configure flycheck, so false positives may have effects =
opposite the intended.

> I also think that packages shouldn't rely on autoloads from other
> packages. I generally dislike autoloads and think they are overused.
> They make programming unnecessarily brittle because they assume not
> only that the load path is set up correctly, but also that the correct
> loaddefs files are already loaded. Autoloads are probably fine for
> interactive commands to avoid unnecessarily loading rarely-used
> packages, but inter-package dependencies should just use 'require'.

I don't necessarily disagree but it would be interesting to hear what =
Stefan thinks about it. Since it's somewhat of an opinionated tool after =
all, it's squarely within our remit to lay down policy...





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 15:09:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 10:09:13 2020
Received: from localhost ([127.0.0.1]:42993 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqdr7-0002kk-0H
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 10:09:13 -0500
Received: from mail-oi1-f181.google.com ([209.85.167.181]:36484)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kqdr4-0002kW-EK
 for 45198 <at> debbugs.gnu.org; Sat, 19 Dec 2020 10:09:11 -0500
Received: by mail-oi1-f181.google.com with SMTP id 9so6378066oiq.3
 for <45198 <at> debbugs.gnu.org>; Sat, 19 Dec 2020 07:09:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=5vJSOwWmpjKDCJpvhk4WPwuXNwjp3xf5k/8yPY+wXrQ=;
 b=BWdHd7fel10AgeS5FAwDR9yWuMGPlZp8X4pWSVi1A9CrKu3kFakWD6BXivfwn7e3Xv
 ViCl0wXocDaQ7nY1JxqR6LH0WG1q49ATJG50+Q5AohKEq9/dnYu9P8Bl5s4ytHs055tb
 rx/d9nvz80+weVHLIQI0fsGI1B3Yt1w2/aKB/Y/QXAnJ+atf+6S9kzZ2ahnOrpzGt7WG
 /yarTH0x+UiET2ic6bNFSxQzsgDa8vfbp+te4iVopYoCBAURVZ+XGuh/WEKXK1+nmL3g
 or/44yLj1DzlUdV3MBiCtvXhIFhfUDvDV9B/OJZHJ8sff9cHpk/YfYkgeSVIDGTY2ZeK
 7cBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=5vJSOwWmpjKDCJpvhk4WPwuXNwjp3xf5k/8yPY+wXrQ=;
 b=ekSrHmejI4dVfhdmOvJtoXByVOzQbIkXXB/DQ1jEUg9mxkupMIW0hSgPLBCitvdCDp
 Jc/s9tTDR/Ig4HV1ZWhlSYfdlKax/WI6NYAA2r+gCflzcV8vLDsx0S88133O974LOcmL
 w/qv3azovzFR3k8SOQG20M0d63Dbql3IeeR5oVxHYUJrRN8uqWDSY9z7hzZUfDnZu6JD
 xxkQVkqGSM7bd01lNH23ysFND2CNdiZ2fuHUrfS7/HRb8EGW1SVxHGZau6LHWICD7UqT
 e0YbgPKF0fmCcq3/UYwhQ5n5Tp/r2jpWN1WQxbDa+HFW0uZm2MUOxkjj6ouLe99TWkKS
 MMrA==
X-Gm-Message-State: AOAM532nV/hdLtkfqQXeUs/xN8DjoOuF6ZvY8Je06LN/iiRFqO/8XCv5
 8nIARDjNMXKB6UiofIoZ95IOqWYLRU+nSpKrPus=
X-Google-Smtp-Source: ABdhPJwfv5FgOSKyQ9EqI8UN6xeXs8T/yURRr9BsZ0opR5oUI6dNH7JmYmcBIe/Yz/qCq5zHtxm9CeMPI9UdUF1Q8a4=
X-Received: by 2002:aca:3b03:: with SMTP id i3mr5965444oia.170.1608390544553; 
 Sat, 19 Dec 2020 07:09:04 -0800 (PST)
MIME-Version: 1.0
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
 <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
In-Reply-To: <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 19 Dec 2020 16:08:52 +0100
Message-ID: <CAArVCkT3dCXrjuRpwVVPc=Zx_ZZg2oztpfk34U7Kb5KLnXx=Cw@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Am Fr., 18. Dez. 2020 um 19:50 Uhr schrieb Mattias Engdeg=C3=A5rd <mattiase=
@acm.org>:
>
> 18 dec. 2020 kl. 16.21 skrev Philipp Stephani <p.stephani2@HIDDEN>:
>
> > Ah, I was talking about the engineering/product management aspect, not
> > about the technical one: If you start with an initially-open sandbox
> > policy, locking it down in future releases is much harder than the
> > other way round.
>
> I assumed we were just building a mechanism for our own consumption at th=
is stage, even if the eventual aim is something available for general use.

I'd say these two questions are somewhat independent of each other.
Even with an internal-only interface, people will start to assume that
reading arbitrary files works.
I'm personally not a huge fan of such internal interfaces though. They
are necessary in some cases, but a high-level UI framework like
Flymake shouldn't need to use them. Besides, since Flymake is released
as an external package, it should rather not use internal interfaces
in the first place.

>
> >  We
> > should definitely run the subprocess with --quick --batch and an empty
> > environment by default, not only for security and speed, but also for
> > reproducibility. That's also what Flycheck does
> > (https://github.com/flycheck/flycheck/blob/a11b789807d1d942d6fcfac17508=
d072b9cf7ba8/flycheck.el#L8435)
>
> Thanks for the reference, and you may very well be right. A counterpoint =
is that since the facility would be enabled by default, a user met with com=
plaints about perfectly fine code will immediately disable the checks and t=
hus foil our plan to nudge his coding habits in a desirable direction.

Maybe, though I wouldn't be so sure. Elisp compilation in Flycheck is
enabled by default and presumably suffers from the same problems.
There are also similar problems with other languages: for example,
when I visit src/lisp.h and enable Flymake, I get 2287 errors, 154
warnings, and 4002 notices (which is an actual problem since the huge
number of overlays makes Emacs sluggish - probably Flymake should just
stop after 20 diagnostics or so...). I totally agree that we need to
keep the false positive rate low, but I wouldn't say that any nonzero
rate would make Flymake useless.

>
> I take it that you don't suggest that we skip on loading autoloads (possi=
bly in the shape of quickstart) though? A bit rough to byte-compile without=
 those, unless we deprecate autoloads altogether.
>

Good question. I'd say we disable them initially and see what happens.
It'll be a while until Emacs 28 gets released, so we have enough time
to gather feedback and make adjustments.
I also think that packages shouldn't rely on autoloads from other
packages. I generally dislike autoloads and think they are overused.
They make programming unnecessarily brittle because they assume not
only that the load path is set up correctly, but also that the correct
loaddefs files are already loaded. Autoloads are probably fine for
interactive commands to avoid unnecessarily loading rarely-used
packages, but inter-package dependencies should just use 'require'.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 18 Dec 2020 18:50:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 18 13:50:26 2020
Received: from localhost ([127.0.0.1]:39904 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqKpe-00015N-9O
	for submit <at> debbugs.gnu.org; Fri, 18 Dec 2020 13:50:26 -0500
Received: from mail1476c50.megamailservers.eu ([91.136.14.76]:41902
 helo=mail118c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1kqKpa-000157-Tc
 for 45198 <at> debbugs.gnu.org; Fri, 18 Dec 2020 13:50:23 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1608317416;
 bh=DRvhXphCF16NoIsHJ9im/Cx0Xy/ncRb+fP34cfM+lvo=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=ZtlG9ShXyvCG1sTUOFM/GELogQzmkJTOMLUTGEeG/BNMJK5GNJRZ6F5v3oOWp+orm
 abmkVD+gsWmyqGtHOKEErQSo4B56RVepZYT9AQTCy3x3Ytiqn6kzPN24fIhq53vl+H
 qUDV33fSRat+ftCIRk0r4wZSuV/inl7GlHh+b4hU=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-064ae655.032-75-73746f71.bbcust.telenor.se
 [85.230.74.6]) (authenticated bits=0)
 by mail118c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BIIoD4O024315; 
 Fri, 18 Dec 2020 18:50:14 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
Date: Fri, 18 Dec 2020 19:50:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3A22728-8650-409B-9406-45A1C191C5F9@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
 <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A782F17.5FDCF9E8.0068, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=HYRqsRM8 c=1 sm=1 tr=0 a=Ni+dBsiEfW2GqKMPYZim9A==:117
 a=Ni+dBsiEfW2GqKMPYZim9A==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=pGLkceISAAAA:8 a=Nb5UD5TeAAAA:20 a=_W6XiWOAtFuLNlGfoowA:9
 a=CjuIK1q_8ugA:10
X-Origin-Country: SE
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

18 dec. 2020 kl. 16.21 skrev Philipp Stephani <p.stephani2@HIDDEN>:

> Ah, I was talking about the engineering/product management aspect, not
> about the technical one: If you start with an initially-open sandbox
> policy, locking it down in future releases is much harder than the
> other way round.

I assumed we were just building a mechanism for our own consumption at =
this stage, even if the eventual aim is something available for general =
use.

>  We
> should definitely run the subprocess with --quick --batch and an empty
> environment by default, not only for security and speed, but also for
> reproducibility. That's also what Flycheck does
> =
(https://github.com/flycheck/flycheck/blob/a11b789807d1d942d6fcfac17508d07=
2b9cf7ba8/flycheck.el#L8435)

Thanks for the reference, and you may very well be right. A counterpoint =
is that since the facility would be enabled by default, a user met with =
complaints about perfectly fine code will immediately disable the checks =
and thus foil our plan to nudge his coding habits in a desirable =
direction.

I take it that you don't suggest that we skip on loading autoloads =
(possibly in the shape of quickstart) though? A bit rough to =
byte-compile without those, unless we deprecate autoloads altogether.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 18 Dec 2020 15:22:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 18 10:22:11 2020
Received: from localhost ([127.0.0.1]:39640 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqHa7-0004Qo-6D
	for submit <at> debbugs.gnu.org; Fri, 18 Dec 2020 10:22:11 -0500
Received: from mail-oo1-f46.google.com ([209.85.161.46]:36133)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kqHZz-0004QC-Qd
 for 45198 <at> debbugs.gnu.org; Fri, 18 Dec 2020 10:22:09 -0500
Received: by mail-oo1-f46.google.com with SMTP id j8so627525oon.3
 for <45198 <at> debbugs.gnu.org>; Fri, 18 Dec 2020 07:22:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=ylzMn+aEF9dAHuCMkyEfkX3soxLiwfI0nQeLUaXm+b0=;
 b=X7/mOvpPESzcQ6ZJqKxaMJYbzlhMigyubN34HfxpZUCCQWvL43m0Y4Rpj6DT9SfS6B
 u6kEgP0Zcu+7V/kcXxxAG7FLG/krWNVZGFcFqNG8u1XRQwC78K4FK6mLO47hJrhh5IYs
 EF0yAbu4vdASQL2WaR4cxqSTErdMLpwDmFmnaXnSEIZoeW4o8YvisYOH7LIoHmcd0blg
 3tABUu+KtCt7yLgMOTCbMbtD5emIrqvNKkOpmNEWwFzjVisxm7zmpmls0gNcQ319LA7U
 9Q02qhenXntuKIR9YIEfEcqKecGJEYLbuikjiozjZTAXPJ51tI7AzpsiT726dgX/ll9i
 IR4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=ylzMn+aEF9dAHuCMkyEfkX3soxLiwfI0nQeLUaXm+b0=;
 b=bfg8Ozl5Ua4pABnD9Ka2Of6SfQxLAgCDQ1xCMQrBvwCIqCeAca1Wg61Tjqp21ZvTA6
 NqZKO6CErT186mRHiuGZh5teCTVqVomnJYk/XY2QJ/JTIsJDKY88CReWSfONJLTRFshB
 3C8ljtDnKAKVIJddbgViWQcjVg85miWNnym5ErsSof0r93DdoR5rK4FlUslL6yYlaIIT
 grz5YnTdNarH0HT0wOGmoY+WTOosvcpikkjDuYKJVTaaQw3eDNVf/LT/aoGZkmjQZsiK
 m0lR5nYX0JoGgUhOc4zGvj36v3irnIEGyBl6EI+r4iqWjLXrQZSDC5WHu2L99dh1Zshb
 XjJw==
X-Gm-Message-State: AOAM533D7la+IgcdfrfnAjWEPtHQ8vnbAUP82hQk09t3Fjj2o5jiCdFW
 hEO6YFWcpEomzmtc9RqUoiLssCHLDPTaIKPHD8g=
X-Google-Smtp-Source: ABdhPJwwLDcEFlGgSqUJQs3p2mY7xM6S8dzUwCsilia75/obdIj7Z4ulY0dasouMstL0ZAU2BikFmNzdq+niNeitMJ8=
X-Received: by 2002:a4a:e8d1:: with SMTP id h17mr3110407ooe.71.1608304917069; 
 Fri, 18 Dec 2020 07:21:57 -0800 (PST)
MIME-Version: 1.0
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
 <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
In-Reply-To: <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Fri, 18 Dec 2020 16:21:45 +0100
Message-ID: <CAArVCkTifUSH4n0L4iNho+JdD40FkJ4udvU-jbxM4arTWQ8Vhw@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Am Do., 17. Dez. 2020 um 18:56 Uhr schrieb Mattias Engdeg=C3=A5rd <mattiase=
@acm.org>:
>
> 17 dec. 2020 kl. 14.08 skrev Philipp Stephani <p.stephani2@HIDDEN>:
>
> > Dynamic libraries tend to start threads for background work, so while
> > there aren't that many, they still exist.
>
> Well, there's no accounting for taste. Still, I'm not ready to close the =
door to possible solutions until they really do appear to lead no way. (It'=
s not an urgent concern since we will need a traditional fork-exec solution=
 first of all.)

Yeah, I didn't want to imply to close the door, just to first start
with what we need to solve the task at hand.

>
> > I haven't tried this out yet, but allowing reads from load-path
> > entries plus the installation directory should be fine.
>
> Assuming this is sufficient; I think autoloaded definitions can specify f=
iles in arbitrary directories, not necessarily in the load-path.

Sure, but things like Flymake byte-compilation are best-effort anyway.
It's fine to (at least initially) not cover a few "exotic" cases.

>
> > Yes, but see my other comment: restricting an open policy after the
> > fact is much harder than opening up an initially-restrictive one, so
> > I'd really start with a restrictive one (no file reading allowed
> > except for allowed directories and files).
>
> Depends on the platform I suppose -- macOS and BSD should work either way=
. On Linux it depends on the method used; I admit not having looked closely=
 at seccomp lately.

Ah, I was talking about the engineering/product management aspect, not
about the technical one: If you start with an initially-open sandbox
policy, locking it down in future releases is much harder than the
other way round.

>
> > The gains are largely realized using threads these days.
>
> Indeed, although forking still has a few niche uses. (For there record I'=
m a firm believer that the fork-exec model was a mistake from its inception=
, but now that it's there...)
>
> Emacs would be better served with threads, too, if it weren't that (I) we=
 don't have a good threading story yet and (II) Elisp code can cause way to=
o much damage at compile time. Fixing either would bring many other benefit=
s!

Yeah, and while there are a few ideas (the "web worker" model looks
most promising), we're not even close to having a design yet.

>
> > I'd think that we'd always run the sandboxed Emacs with --quick
> > --batch and an empty environment (to provide for some reproducibility
> > and avoid LD_PRELOAD attacks etc.), and then startup tends to be fast
> > enough (emacs -Q -batch takes ~50 ms on my system).
>
> That's not quite fair; the byte-compiler needs the right load-path and au=
toload definitions, and the byte-compiler itself needs to be loaded as well=
. (Anyone who can set LD_PRELOAD already has the machine.)
>
> The easiest way is to run the user's init file. Perhaps it's possible to =
just transmit a list of paths and packages to the subprocess as arguments b=
ut the user may have things loaded or defined outside the standard package =
manager.
>

We should be very hesitant to use the easiest way. Often it's the
wrong way, and fixing things after the fact tends to be hard. Again,
the goal is not to provide a perfect solution that works for all ELisp
files, but something that works well for "typical" use cases. We
should definitely run the subprocess with --quick --batch and an empty
environment by default, not only for security and speed, but also for
reproducibility. That's also what Flycheck does
(https://github.com/flycheck/flycheck/blob/a11b789807d1d942d6fcfac17508d072=
b9cf7ba8/flycheck.el#L8435)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 17 Dec 2020 17:56:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 17 12:56:01 2020
Received: from localhost ([127.0.0.1]:36961 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kpxVQ-000144-Mw
	for submit <at> debbugs.gnu.org; Thu, 17 Dec 2020 12:56:00 -0500
Received: from mail70c50.megamailservers.eu ([91.136.10.80]:37548)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1kpxVO-00013u-5f
 for 45198 <at> debbugs.gnu.org; Thu, 17 Dec 2020 12:56:00 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1608227756;
 bh=JVq79grn5sYaO8lzjeT2KAae2tU5HjJtriItnpFETig=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=FxShkDelGQ0Ez98qJNW37bVQcxQw7GUDkUTpBu16Ksf0/Zi478Nx3FSG2vD2k5//Z
 LRGprBZNsS4S4SNom6wZGyoE2S52RENHZY7KGS7Tg02/RdV6gvxSj5QSJg5DAStxDO
 qwRaA6iA8Lk7CY+4rLNR6aHAX6+PJqi/MsKXhOYY=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se
 [188.150.171.71]) (authenticated bits=0)
 by mail70c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BHHtqOu001687; 
 Thu, 17 Dec 2020 17:55:54 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
Date: Thu, 17 Dec 2020 18:55:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <26556EDE-9133-450F-9181-2859E058677C@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
 <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A782F27.5FDB9BAC.000F, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=UIOj4xXy c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117
 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=pGLkceISAAAA:8 a=DTTHb2eM3JguN3yHLMoA:9 a=CjuIK1q_8ugA:10
X-Origin-Country: SE
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

17 dec. 2020 kl. 14.08 skrev Philipp Stephani <p.stephani2@HIDDEN>:

> Dynamic libraries tend to start threads for background work, so while
> there aren't that many, they still exist.

Well, there's no accounting for taste. Still, I'm not ready to close the =
door to possible solutions until they really do appear to lead no way. =
(It's not an urgent concern since we will need a traditional fork-exec =
solution first of all.)

> I haven't tried this out yet, but allowing reads from load-path
> entries plus the installation directory should be fine.

Assuming this is sufficient; I think autoloaded definitions can specify =
files in arbitrary directories, not necessarily in the load-path.

> Yes, but see my other comment: restricting an open policy after the
> fact is much harder than opening up an initially-restrictive one, so
> I'd really start with a restrictive one (no file reading allowed
> except for allowed directories and files).

Depends on the platform I suppose -- macOS and BSD should work either =
way. On Linux it depends on the method used; I admit not having looked =
closely at seccomp lately.

> The gains are largely realized using threads these days.

Indeed, although forking still has a few niche uses. (For there record =
I'm a firm believer that the fork-exec model was a mistake from its =
inception, but now that it's there...)

Emacs would be better served with threads, too, if it weren't that (I) =
we don't have a good threading story yet and (II) Elisp code can cause =
way too much damage at compile time. Fixing either would bring many =
other benefits!

> I'd think that we'd always run the sandboxed Emacs with --quick
> --batch and an empty environment (to provide for some reproducibility
> and avoid LD_PRELOAD attacks etc.), and then startup tends to be fast
> enough (emacs -Q -batch takes ~50 ms on my system).

That's not quite fair; the byte-compiler needs the right load-path and =
autoload definitions, and the byte-compiler itself needs to be loaded as =
well. (Anyone who can set LD_PRELOAD already has the machine.)

The easiest way is to run the user's init file. Perhaps it's possible to =
just transmit a list of paths and packages to the subprocess as =
arguments but the user may have things loaded or defined outside the =
standard package manager.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 17 Dec 2020 13:08:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 17 08:08:26 2020
Received: from localhost ([127.0.0.1]:35042 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kpt17-0001dl-Ei
	for submit <at> debbugs.gnu.org; Thu, 17 Dec 2020 08:08:25 -0500
Received: from mail-ot1-f54.google.com ([209.85.210.54]:35333)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kpt14-0001dU-9j
 for 45198 <at> debbugs.gnu.org; Thu, 17 Dec 2020 08:08:24 -0500
Received: by mail-ot1-f54.google.com with SMTP id i6so27187159otr.2
 for <45198 <at> debbugs.gnu.org>; Thu, 17 Dec 2020 05:08:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=ERpuRURCF52tkm8ZeFhpWXGFRgcXRWNOWpe7PvC9gGo=;
 b=R3Qqb/fvCknLoVwU6R/lOXomup+owvCUgMD1oTC5ETBYmWH5JKRkE0NV9QCpU6m7wU
 zK3YUSrhvu9uDSWwR2zeCPQlUY34wzc6SGJb9oDHQx39lASHwHUhr/FiesEoD5iD5DzK
 AxGErVsa/RlHKP5jALQu8IejWosprJmldKSRCmlpG8k6Cr6nN4Lu0DlLYEt+QPN+36hS
 ywKcKKbTiiYg2ml0R+SL5B/ojqXXqMdpzIl1F3aAfglfDbEUxczkW9cbszRKMNptBw8C
 yJpu4ka24GeBy1WAnq3IxPWNk8xABHen+7dw5fwp/qvgRZHLFbhTFskBNfMhPeakPOiX
 ADFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=ERpuRURCF52tkm8ZeFhpWXGFRgcXRWNOWpe7PvC9gGo=;
 b=dbwfJ7i+zGg1GVL+mWF09ZwEa8O0q6hl77sMB+kibWdy69sKQRAeLiMuFI5kNQ2toV
 xrPfl+rI0hKrekIL9pp/cyjyKxlREQmCNsa7r3wCHFr2qD22FjfQrnZzBTaxQRJMhMCT
 gLoOn6Sm+RZDYRkTC7IhcXnKvKMvKrqnkUQbQuVyx7IvdOzqUbWVwb3kB+z8Deyq9IyE
 Rpguz3/r6XIQzsyD7zZjHAXROPmYwL4SOUXg5GFdqNBYxwf7+iK3xUAAWhCxe612B1Fz
 i0aUFTpO+bOFRd3nebHH7WwWDJlWWERKiZxxLoPxcvtT0pxLSw3USTrW1zFkryM1ycXf
 5isQ==
X-Gm-Message-State: AOAM532x0Y8eBEx7uLTttV2nh6jx1AhzDFDihTmu0SFEvUo1cOnmsB31
 kRg3f2nsDd4wShJc66hwkAThqaLPnetEj48AceI=
X-Google-Smtp-Source: ABdhPJwRgXB17gpiIMuGynvXdlk5DUpgfQm3weYYqrS0eqdI4Wr15SwQ/IxsSwGOs9J6zfsdvO9eXbaa4MLp0RW9s4M=
X-Received: by 2002:a9d:72c4:: with SMTP id d4mr29849025otk.149.1608210496348; 
 Thu, 17 Dec 2020 05:08:16 -0800 (PST)
MIME-Version: 1.0
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
In-Reply-To: <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Thu, 17 Dec 2020 14:08:04 +0100
Message-ID: <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Am Mo., 14. Dez. 2020 um 16:59 Uhr schrieb Mattias Engdeg=C3=A5rd <mattiase=
@acm.org>:
>
> 14 dec. 2020 kl. 14.44 skrev Philipp Stephani <p.stephani2@HIDDEN>:
>
> > Yes, it's not strictly required (as in, seccomp and unshare nominally
> > work at any point), though I think enabling sandboxing while user code
> > has already run can have confusing/unanticipated consequences. For
> > example, other threads might already be running in parallel, and they
> > would then suddenly be blocked from making some syscalls, potentially
> > in the middle of a critical section or similar.
>
> There shouldn't be many threads running in non-interactive mode,

Dynamic libraries tend to start threads for background work, so while
there aren't that many, they still exist.

> and those that are must be expected to work with the added restrictions b=
ecause why should they be exempt and what are they doing that we want to fo=
rbid anyway? It seems a bit far-fetched and probably not an immediate conce=
rn.

Libraries (and Emacs itself) can do arbitrary background processing as
an implementation detail, so we'd need to take that into account. I
agree though that this isn't a problem in practice, and, if at all,
requires some adjustments to the policy.
Just do give an example:
https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob;f=3Dnptl/pthread_create.=
c;h=3Dbad4e57a845bd3148ad634acaaccbea08b04dbbd;hb=3DHEAD#l393
assumes that set_robust_list will work if it worked once. In the case
of an Emacs sandbox, threads are started before entering main (through
dynamic initialization and dynamic linking), so the function assumes
that set_robust_list works. (In that case we can just allow
set_robust_list as it's not dangerous.)

>
> That said, it is very much an implementation matter -- the run-function-i=
n-sandbox Lisp interface seems better than the original enter-sandbox becau=
se we get more ways to write the code. Thanks for proposing it!

Sure, I also don't mind adding a load-seccomp-filter function for
post-main invocation. Right now I believe it's not needed though.

>
> > For example, to achieve some amount of capability-based
> > security, you'd open files before sandboxing and then forbid the open
> > syscall, but that's not really possible with the current Emacs API
> > (which doesn't provide any access to open files).
>
> Well, almost -- elisp processes serve some of the purposes of open file d=
escriptors, at least for pipes and sockets.
>
> Is it really is practical to restrict file-system visibility? A spawned b=
yte-compiler will need to read almost arbitrary elisp files (autoload, 'req=
uire' calls) whose exact names are only known at runtime. Were you planning=
 to build a name-space from a skeleton populated by load-path mounts?

I haven't tried this out yet, but allowing reads from load-path
entries plus the installation directory should be fine.

>
> My initial thought was simply inhibit pretty much everything except readi=
ng files and writing to already open descriptors (or just stdout/stderr), o=
n the grounds that while it would enable an adversary to read anything, exf=
iltration would be difficult.

Yes, but see my other comment: restricting an open policy after the
fact is much harder than opening up an initially-restrictive one, so
I'd really start with a restrictive one (no file reading allowed
except for allowed directories and files).

>
> (Some side-channels may be worth thinking about: if the machine cannot tr=
ust its file servers, it is possible to exfiltrate data to an already compr=
omised server merely by reading. But then there are probably more direct ap=
proaches.)
>
> > Even on Unix, a fork that's not immediately followed by an exec or
> > exit tends to not work any more. Lots of libraries nowadays assume
> > that the "weird in-between state" after a fork doesn't exist
> > permanently, and only a small number of async-signal-safe syscalls are
> > guaranteed to work between fork and exec.
>
> Yes, and I'm aware of the difficulties but wouldn't dismiss it out of han=
d since the gains are attractive. The main trouble stems from fork only bri=
nging the calling thread into the new process, which may cause deadlock if =
those threads were holding locks which the forked process goes on to acquir=
e later on. (pthread_atfork is supposed to be used by threaded libraries bu=
t typically isn't.)

Yes, and because libraries can and do start arbitrary threads, this
issue can't really be mitigated and makes fork without exec extremely
unsafe and largely useless.
The gains are largely realized using threads these days.

>
> It does work given some care (and I have done so in the past to good effe=
ct); it's mainly a matter of not touching anything that you don't want to u=
se anyway such as GUI frameworks. In Emacs, this would be done in some sort=
 of become_noninteractive function which ensures that future program flow w=
ill not involve any GUI code whatsoever.

I don't think that's enough, even linking against some libraries
already causes background threads to spin up.

>
> Let's see what latency we get from spawning a typically overloaded Emacs =
configuration first.
>

I'd think that we'd always run the sandboxed Emacs with --quick
--batch and an empty environment (to provide for some reproducibility
and avoid LD_PRELOAD attacks etc.), and then startup tends to be fast
enough (emacs -Q -batch takes ~50 ms on my system).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 14 Dec 2020 15:59:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 14 10:59:50 2020
Received: from localhost ([127.0.0.1]:53902 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koqGM-0005v4-BI
	for submit <at> debbugs.gnu.org; Mon, 14 Dec 2020 10:59:50 -0500
Received: from mail1467c50.megamailservers.eu ([91.136.14.67]:46476
 helo=mail268c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1koqGJ-0005up-KE
 for 45198 <at> debbugs.gnu.org; Mon, 14 Dec 2020 10:59:48 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1607961581;
 bh=Oj5Q//4lDswoLErmbEEJih8a143ppiuA1udskDE/56Y=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=C7kiHxyTmuF3FvD39bAgm07RjFCo2wDULZFBBssWq1WJKs6/MI/U/A7uSqtJ8AyK/
 dkGvZBdNm5G2YstApeBLgznZ7qBVVt+KIhBqJlz0zRFAmLmVAoTC9D/536RnGFvkUm
 Yb25MejvoCa+lLD0l6bGBdIlcQnVuhcbBSzhDQ2c=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se
 [188.150.171.71]) (authenticated bits=0)
 by mail268c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BEFxS6R018925; 
 Mon, 14 Dec 2020 15:59:36 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
In-Reply-To: <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
Date: Mon, 14 Dec 2020 16:59:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4789EA5-BCBC-4B10-BA52-3329DB9C9E42@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A782F29.5FD78BEC.004F, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=J+PUEzvS c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117
 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=pGLkceISAAAA:8 a=ktOLASWPuep7Hyu_2dEA:9 a=CjuIK1q_8ugA:10
X-Origin-Country: SE
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: 14 dec. 2020 kl. 14.44 skrev Philipp Stephani
 <p.stephani2@HIDDEN>:
 > Yes, it's not strictly required (as in, seccomp and unshare nominally >
 work at any point), though I think enabling sandboxing while user code >
 has already run can have confusing/unanticipated cons [...] 
 Content analysis details:   (1.4 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 0.4 KHOP_HELO_FCRDNS       Relay HELO differs from its IP's reverse DNS
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

14 dec. 2020 kl. 14.44 skrev Philipp Stephani <p.stephani2@HIDDEN>:

> Yes, it's not strictly required (as in, seccomp and unshare nominally
> work at any point), though I think enabling sandboxing while user code
> has already run can have confusing/unanticipated consequences. For
> example, other threads might already be running in parallel, and they
> would then suddenly be blocked from making some syscalls, potentially
> in the middle of a critical section or similar.

There shouldn't be many threads running in non-interactive mode, and =
those that are must be expected to work with the added restrictions =
because why should they be exempt and what are they doing that we want =
to forbid anyway? It seems a bit far-fetched and probably not an =
immediate concern.

That said, it is very much an implementation matter -- the =
run-function-in-sandbox Lisp interface seems better than the original =
enter-sandbox because we get more ways to write the code. Thanks for =
proposing it!

> For example, to achieve some amount of capability-based
> security, you'd open files before sandboxing and then forbid the open
> syscall, but that's not really possible with the current Emacs API
> (which doesn't provide any access to open files).

Well, almost -- elisp processes serve some of the purposes of open file =
descriptors, at least for pipes and sockets.

Is it really is practical to restrict file-system visibility? A spawned =
byte-compiler will need to read almost arbitrary elisp files (autoload, =
'require' calls) whose exact names are only known at runtime. Were you =
planning to build a name-space from a skeleton populated by load-path =
mounts?

My initial thought was simply inhibit pretty much everything except =
reading files and writing to already open descriptors (or just =
stdout/stderr), on the grounds that while it would enable an adversary =
to read anything, exfiltration would be difficult.

(Some side-channels may be worth thinking about: if the machine cannot =
trust its file servers, it is possible to exfiltrate data to an already =
compromised server merely by reading. But then there are probably more =
direct approaches.)

> Even on Unix, a fork that's not immediately followed by an exec or
> exit tends to not work any more. Lots of libraries nowadays assume
> that the "weird in-between state" after a fork doesn't exist
> permanently, and only a small number of async-signal-safe syscalls are
> guaranteed to work between fork and exec.

Yes, and I'm aware of the difficulties but wouldn't dismiss it out of =
hand since the gains are attractive. The main trouble stems from fork =
only bringing the calling thread into the new process, which may cause =
deadlock if those threads were holding locks which the forked process =
goes on to acquire later on. (pthread_atfork is supposed to be used by =
threaded libraries but typically isn't.)

It does work given some care (and I have done so in the past to good =
effect); it's mainly a matter of not touching anything that you don't =
want to use anyway such as GUI frameworks. In Emacs, this would be done =
in some sort of become_noninteractive function which ensures that future =
program flow will not involve any GUI code whatsoever.

Let's see what latency we get from spawning a typically overloaded Emacs =
configuration first.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 14 Dec 2020 15:38:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 14 10:38:02 2020
Received: from localhost ([127.0.0.1]:53849 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kopvF-0003Dm-PI
	for submit <at> debbugs.gnu.org; Mon, 14 Dec 2020 10:38:02 -0500
Received: from mail-oo1-f42.google.com ([209.85.161.42]:40812)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kopvD-0003DU-U5
 for 45198 <at> debbugs.gnu.org; Mon, 14 Dec 2020 10:38:00 -0500
Received: by mail-oo1-f42.google.com with SMTP id 9so4035338ooy.7
 for <45198 <at> debbugs.gnu.org>; Mon, 14 Dec 2020 07:37:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=E0iEc0rosFKPXqrWtEPjgp5aPAzhaWtsrs1+mwtwc8M=;
 b=Bbx3s8idf8Xlp9Z3X22cHHSmZ73OImzUw70Zg7pWuqIikH1ydMhFjasl97Xp6woFla
 zmsRRpcwrGwlz1Bf2h4Dva4Qiprtuk5ZfmgVILMR1QSgo4t/Eg7hdS/1gHazblY9ynB9
 7mZyNjGvEepD1BPoOjg6awv1Mp7eBvZLb9WwLEJMVMG0RCcTsdzAzoChomVcQYcSL015
 eDxpsPiS+Me7URL/yVmAjWAxGI9DQ6hXDAkm1/b/wQQUjMRqSiFNAi7ELFn5LFFpw34i
 0n8rPdtvxJJOs8TSe6/9vFg5/fT9uHCA3SgzKxiV7wiQR8yd9rw1Mm2g1j+pNDq9iJAg
 VAUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=E0iEc0rosFKPXqrWtEPjgp5aPAzhaWtsrs1+mwtwc8M=;
 b=Vox2b056zRp0ujWWPAbuIZKrDm3Q4b3Z61oU85viE1m2ErKDnnpkkEvO06k4aWP1f2
 60HWwmnatNaDxTYe3n3gaA9wPTb++V7RDglech+2u9Ex5qg5C0jJnLOKxq9SXu3T8Qu6
 aNvRjIxCG5SxoHWIrSpMbMzyx0wqf1fC89vNspCIKym0b3p37WEv+8mFay9RnSlYfFIL
 ONzgz2Xx/cn0OQlJ+fh66Yl+jyS0Yu99O4iKOXG8TGizuIFRsAYJmTzbMtjRyJf4v9pR
 pqyQWLUsF2j4J+9zobTq1oAZW1IOQwmFGZA4PZpC061+NjmPWoBbysFW7dJWfyR7ut6r
 Q1KQ==
X-Gm-Message-State: AOAM531p9R5ANf4kkF5dXrxWQQhWsygYj8vC8tWmRr2Dz0nm5YClmrzJ
 a6Py1iozJ/XENcY7hdFqz0UoE9GEQxaEN8H+Oew=
X-Google-Smtp-Source: ABdhPJy4fK82LyyIhQ9lvvde6iEsjhhsCkpu4FgeQSIi3MaeThbNrshTgpqAJ4uWuzJMdDlU3ugFTh+bhc1/dSzDHDg=
X-Received: by 2002:a4a:e8d1:: with SMTP id h17mr2805453ooe.71.1607960273852; 
 Mon, 14 Dec 2020 07:37:53 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
 <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
 <jwv4kkoiim5.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwv4kkoiim5.fsf-monnier+emacs@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Mon, 14 Dec 2020 16:37:42 +0100
Message-ID: <CAArVCkSAzA81Y0j_zcne+jMm+_ox-vDEhHwBNQqOtg5vtVwuvg@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Am Mo., 14. Dez. 2020 um 15:44 Uhr schrieb Stefan Monnier
<monnier@HIDDEN>:
>
> > In some way certainly, but it's not necessarily through stdout. I tend
> > to write potential output into a file whose filename is passed on the
> > command line. That's more robust than stdout (which often contains
> > spurious messages about loading files etc).
>
> Hmm... but that requires write access to some part of the file system,
> so it requires a finer granularity of control.

When using mount namespaces, that comes at a low cost: you mount
exactly those files that you want to write as writable filesystems,
and read-only files as read-only.

> I'd much rather limit
> the output to something equivalent to a pipe (the implementation of the
> sandboxing doesn't have to use stdout for that if that's a problem).

It's definitely true that only accessing open file descriptors is more
secure and simpler ("capability-based security"). However, I assume
that generic Elisp code doesn't work too well if it can't do things
like create temporary files. I've found 211 calls to make-temp-file in
the Emacs codebase alone, and I'd be surprised if none of them were
applicable to sandboxed processes.

>
> >> Also, I think the async option is the most important one.  How 'bout:
> >>     (sandbox-start FUNCTION)
> >>     Lunch a sandboxed Emacs subprocess running FUNCTION.
> > Passing a function here might be confusing because e.g. lexical
> > closures won't work.
>
> What makes you think they don't?

Hmm, you mean printing and reading closure objects? It might work,
though I don't know how portable/robust it is.

>
> > It might be preferable to pass a form and state
> > that both dynamic and lexical bindings are ignored.
>
> If closures turn out to be a problem I'd rather use FUNCTION + VALUES
> than FORM (using FORM implies the use of `eval`, and you have to think
> of all those kitten that'll suffer if we do that).

It is always eval, because that's how Elisp works. How else would you
deserialize and execute code than with read + eval?

>
> >>     Returns a process object.
> > Depending how much we care about forward compatibility, it might be
> > better to return an opaque sandbox object (which will initially wrap a
> > process object).
>
> We always use process objects to represent file-descriptors, so I can't
> find any good reason why this one should be different or why an
> implementation might find it difficult to expose a process object.

That's a fair point, but when thinking about forwards-compatibility we
might want to anticipate reasons that we currently can't think of.

>
> >>     FUNCTION is called with no arguments and it can use `sandbox-read`
> >>     to read the data sent to the process object via `process-send-string`,
> >>     and `sandbox-reply` to send back a reply to the parent process
> >>     (which will receive it via its `process-filter`).
> > That is, sandbox-read and sandbox-reply just read/write stdin/stdout?
>
> While it may use stdin/stdout internally, I can imagine good reasons why
> we'd want to use some other file descriptors.

If the process can write to stdout, then users will do that. Users
would probably just try whether 'print' works, and use it if it does.
So if you want a specialized function, then we'd need to make sure
that 'print' doesn't work (e.g. by having the parent process only read
the new pipe).

>
> > That would certainly work, but (a) it doesn't really have anything to
> > do with sandboxing, so these functions should rather be called
> > stdin-read and stdout-write or similar,
>
> I think "the right thing" would be to represent the parent as a process
> object inside the child.  I proposed dedicated functions only because
> but when it uses stdin/stdout, providing a process object seems awkward
> to implement.

It would be a file descriptor in all cases, so we might as well use a
pipe process (and introduce a function to write to a pipe). Stdout
isn't really different from other open file descriptors.
We'd need some special support for other file descriptors though, as
we'd need to make sure to not open them with O_CLOEXEC.

>
> >>     The sandboxed process has read access to all the local files
> >>     but no write access to them, nor any access to the network or
> >>     the display.
> > This might be a bit too specific. I'd imagine we'd want to restrict
> > reading files to the absolute minimum (files that Emacs itself needs
> > plus a fixed set of input files/directories known in advance), but
> > often allow writing some output files.
>
> I'm trying to design an API which can be made to work in as many
> circumstances as possible without imposing too high a maintenance
> burden.  So while I agree that it'd be better to limit the set of files
> that can be read and to allow writing to some files, I think I'd rather
> start with something more crude.
>
> We can refine it later if/when we have more experience with how it's
> used, and how it's implemented in the various OSes.

Even without specific experience, we can definitely say that
restricting something later is much harder than lifting restrictions.
So if we'd start with a policy that allows full read access, we'd have
a very hard time restricting that later. IOW, I'd be fine with not
providing write access to files (with the exception of maybe a
process-local tmpfs), but I'd try to restrict reading right from the
start to the installation directory and other known sources like the
load path.

>
> >> >> - I suspect we'll still want to use the extra "manual" checks I put in
> >> >>   my code (so as to get clean ELisp errors when bumping against the
> >> >>   walls of the sandbox, and because of the added in-depth security).
> >> > That's reasonable, though I'm worried that it will give users a false
> >> > sense of security.
> >> That would only be the case if we don't additionally use process-level
> >> isolation, right?
> > My worry is that people see a function like enter-sandbox and then
> > assume that Emacs will be secure after calling it, without actually
> > verifying the security implications.
>
> This seems universally true and hence suggests we should just forget
> about this idea of providing a sandbox functionality.  IOW I'm not sure
> what this has to do with the `ensure_no_sandbox` calls I'm suggesting
> we keep.

Seccomp and namespaces are battle-tested kernel-level security
features. If we use them, we'll have a much better chance at providing
an actually secure sandbox.

>
> > I've looked into this, and what I'd suggest for now is:
> > 1. Add a --seccomp=FILE command-line option that loads seccomp filters
> > from FILE and applies them directly after startup (first thing in
> > main). Why do this in Emacs? Because that's the easiest way to prevent
> > execve. When installing a seccomp filter in a separate process, execve
> > needs to be allowed because otherwise there'd be no way to execute the
> > Emacs binary. While there are workarounds (ptrace, LD_PRELOAD), it's
> > easiest to install the seccomp filter directly in the Emacs process.
> > 2. Generate appropriate seccomp filters using libseccomp or similar.
> > 3. In the sandboxing functions, start Emacs with bwrap to set up
> > namespaces and invoke Emacs with the new --seccomp flag.
>
> Sounds OK, tho I must say I don't understand why we care particularly
> about disallowing execve inside the bwrap jail.  AFAIK anything that an
> external process can do can also be done directly by Emacs since ELisp
> is a fairly fully-featured language (since there's nothing like setuid
> inside a bwrap jail).  I mean, I agree that we want to disallow running
> subprocesses, but can't think of a good reason why we would need this to
> be 100%, so we could rely on `ensure_no_sandbox` for that.

It's basically just another way to make the attack surface smaller and
provide defense in depth. If we allow execve, then suddenly the attack
surface increases to include all possible binaries that Emacs might
execute.
I've implemented the --seccomp flag, and it's really benign - mapping
the input file plus one or two syscalls. It's also strictly optional
and doesn't preclude using other technologies.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 14 Dec 2020 14:48:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 14 09:48:57 2020
Received: from localhost ([127.0.0.1]:51689 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kop9l-0001R4-Gn
	for submit <at> debbugs.gnu.org; Mon, 14 Dec 2020 09:48:57 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63864)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kop9j-0001Qq-Qd
 for 45198 <at> debbugs.gnu.org; Mon, 14 Dec 2020 09:48:56 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7FBB280967;
 Mon, 14 Dec 2020 09:48:50 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 36ED780904;
 Mon, 14 Dec 2020 09:48:49 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1607957329;
 bh=jsw4TqrMyZvUVgKKJRm1lFRRvHciN4k6p4IljXQNDDw=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=T9gCBGn+neUY6xD6XJ0g3QrWCUlZXMWt6U1w4y5pJ3w599QSQVH0u7Ek8yQMWbiMo
 gI18Y6KKS9/AiBAw/rrO/9WtJiVvb8nTE0RD1/i47xOEp9a6men31/+y3CV/Nc3D42
 1ZKDDjbMfA3CLgzkmgJQRWg0mVHcT0FyV2FPiMCvrgbuv58zh/GmgLFdLrsTYNe3W3
 o5Seittnx2jbScxxbDLq+0t2JzT7k5B/Ye7IUFkodf9RPscozF2fC3pzBhENg2KFRP
 1coIvd7LfDjBaY1ON/hwJ5640zNxkRwYrWWuZIxtcxBn6G7FfPpHYe4MCJNGeiVTlY
 ZKU28970CIbMw==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E846E12023D;
 Mon, 14 Dec 2020 09:48:48 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwvy2i0h2dj.fsf-monnier+emacs@HIDDEN>
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
 <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
Date: Mon, 14 Dec 2020 09:48:47 -0500
In-Reply-To: <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
 (Philipp Stephani's message of "Mon, 14 Dec 2020 14:44:25 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.064 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>,
 Mattias =?windows-1252?Q?Engdeg=E5rd?= <mattiase@HIDDEN>,
 45198 <at> debbugs.gnu.org,
 =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> namespace also don't work in multithreaded processes. Allowing
> sandboxing (at least for now) only at process startup avoids such
> issues and should be good enough for the given use case (Flymake
> background compilation), since we need to start a new process anyway.

BTW, while flymake does already use a background process, I think
there's a deeper reason why we'll always need a separate process:
there's no way to exit a sandbox.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 14 Dec 2020 14:44:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 14 09:44:41 2020
Received: from localhost ([127.0.0.1]:51680 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kop5d-0001K2-Gq
	for submit <at> debbugs.gnu.org; Mon, 14 Dec 2020 09:44:41 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9514)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kop5b-0001Jq-LQ
 for 45198 <at> debbugs.gnu.org; Mon, 14 Dec 2020 09:44:40 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EC8F68090B;
 Mon, 14 Dec 2020 09:44:33 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0460680085;
 Mon, 14 Dec 2020 09:44:32 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1607957072;
 bh=aZ5BxGEzROpTuBb7t+uhCXQSxYPcNQcxWwozLgGass8=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=fG+kutwutPNzN6ZONzFA9h4X1Vba6wG3nxCPQC/qRjA5IwRgA56k+i6RxCNFhqQeJ
 j687HMSVnnHiIclCa0bqf9+DKP5yTVcTKi8nxKJdHQZtONcWiX0MFQKANzIzrZuh1K
 uf/nsXOLxcsI/9Bd50Ltt60bbJUg+trOhc7hDTJIN2Q9c5pS2Z1235tnBOtAWCB7pw
 fgpNUQZCEO3npUaBcRtILCkdSLiRLAww2eOpH4+eEOKN8BkavfZAontD0JT4ODOYX5
 Q2npyCuuXN46lrnuILKsFX78zFk0YLseYyPrc6MuPfortGliUMxUqwUNSYyyZvD7iC
 BRShrwvMsg59A==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BE1C11203AB;
 Mon, 14 Dec 2020 09:44:31 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwv4kkoiim5.fsf-monnier+emacs@HIDDEN>
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
 <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
Date: Mon, 14 Dec 2020 09:44:30 -0500
In-Reply-To: <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
 (Philipp Stephani's message of "Mon, 14 Dec 2020 12:05:09 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.065 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?windows-1252?B?Sm/j?= =?windows-1252?B?byBU4XZvcmE=?=
 <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> In some way certainly, but it's not necessarily through stdout. I tend
> to write potential output into a file whose filename is passed on the
> command line. That's more robust than stdout (which often contains
> spurious messages about loading files etc).

Hmm... but that requires write access to some part of the file system,
so it requires a finer granularity of control.  I'd much rather limit
the output to something equivalent to a pipe (the implementation of the
sandboxing doesn't have to use stdout for that if that's a problem).

>> Also, I think the async option is the most important one.  How 'bout:
>>     (sandbox-start FUNCTION)
>>     Lunch a sandboxed Emacs subprocess running FUNCTION.
> Passing a function here might be confusing because e.g. lexical
> closures won't work.

What makes you think they don't?

> It might be preferable to pass a form and state
> that both dynamic and lexical bindings are ignored.

If closures turn out to be a problem I'd rather use FUNCTION + VALUES
than FORM (using FORM implies the use of `eval`, and you have to think
of all those kitten that'll suffer if we do that).

>>     Returns a process object.
> Depending how much we care about forward compatibility, it might be
> better to return an opaque sandbox object (which will initially wrap a
> process object).

We always use process objects to represent file-descriptors, so I can't
find any good reason why this one should be different or why an
implementation might find it difficult to expose a process object.

>>     FUNCTION is called with no arguments and it can use `sandbox-read`
>>     to read the data sent to the process object via `process-send-string`,
>>     and `sandbox-reply` to send back a reply to the parent process
>>     (which will receive it via its `process-filter`).
> That is, sandbox-read and sandbox-reply just read/write stdin/stdout?

While it may use stdin/stdout internally, I can imagine good reasons why
we'd want to use some other file descriptors.

> That would certainly work, but (a) it doesn't really have anything to
> do with sandboxing, so these functions should rather be called
> stdin-read and stdout-write or similar,

I think "the right thing" would be to represent the parent as a process
object inside the child.  I proposed dedicated functions only because
but when it uses stdin/stdout, providing a process object seems awkward
to implement.

>>     The sandboxed process has read access to all the local files
>>     but no write access to them, nor any access to the network or
>>     the display.
> This might be a bit too specific. I'd imagine we'd want to restrict
> reading files to the absolute minimum (files that Emacs itself needs
> plus a fixed set of input files/directories known in advance), but
> often allow writing some output files.

I'm trying to design an API which can be made to work in as many
circumstances as possible without imposing too high a maintenance
burden.  So while I agree that it'd be better to limit the set of files
that can be read and to allow writing to some files, I think I'd rather
start with something more crude.

We can refine it later if/when we have more experience with how it's
used, and how it's implemented in the various OSes.

>> >> - I suspect we'll still want to use the extra "manual" checks I put in
>> >>   my code (so as to get clean ELisp errors when bumping against the
>> >>   walls of the sandbox, and because of the added in-depth security).
>> > That's reasonable, though I'm worried that it will give users a false
>> > sense of security.
>> That would only be the case if we don't additionally use process-level
>> isolation, right?
> My worry is that people see a function like enter-sandbox and then
> assume that Emacs will be secure after calling it, without actually
> verifying the security implications.

This seems universally true and hence suggests we should just forget
about this idea of providing a sandbox functionality.  IOW I'm not sure
what this has to do with the `ensure_no_sandbox` calls I'm suggesting
we keep.

> I've looked into this, and what I'd suggest for now is:
> 1. Add a --seccomp=FILE command-line option that loads seccomp filters
> from FILE and applies them directly after startup (first thing in
> main). Why do this in Emacs? Because that's the easiest way to prevent
> execve. When installing a seccomp filter in a separate process, execve
> needs to be allowed because otherwise there'd be no way to execute the
> Emacs binary. While there are workarounds (ptrace, LD_PRELOAD), it's
> easiest to install the seccomp filter directly in the Emacs process.
> 2. Generate appropriate seccomp filters using libseccomp or similar.
> 3. In the sandboxing functions, start Emacs with bwrap to set up
> namespaces and invoke Emacs with the new --seccomp flag.

Sounds OK, tho I must say I don't understand why we care particularly
about disallowing execve inside the bwrap jail.  AFAIK anything that an
external process can do can also be done directly by Emacs since ELisp
is a fairly fully-featured language (since there's nothing like setuid
inside a bwrap jail).  I mean, I agree that we want to disallow running
subprocesses, but can't think of a good reason why we would need this to
be 100%, so we could rely on `ensure_no_sandbox` for that.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 14 Dec 2020 13:44:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 14 08:44:44 2020
Received: from localhost ([127.0.0.1]:51623 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koo9b-0008EG-Vp
	for submit <at> debbugs.gnu.org; Mon, 14 Dec 2020 08:44:44 -0500
Received: from mail-ot1-f68.google.com ([209.85.210.68]:45030)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1koo9a-0008E4-Qp
 for 45198 <at> debbugs.gnu.org; Mon, 14 Dec 2020 08:44:43 -0500
Received: by mail-ot1-f68.google.com with SMTP id f16so15684792otl.11
 for <45198 <at> debbugs.gnu.org>; Mon, 14 Dec 2020 05:44:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=B4X35+dCh66GLhjJLrDaEmWkU4PBMcqZb4KydkQDfPI=;
 b=P/eDWQpS6niuvxbjQZPBPbTwIDShIJBUA0RUHq7Z64CmzEywr2VJ4NRuoykvxbDLap
 2tevc8kWvXLmuoWvApAFiyPQ2W1IH8fsv/QpnuDcx9TEFgU/530J5Fm8UYRwzlE5RwU0
 fyzWswhpnZkxPN32YNzsiWoLbGTnoTkJqsnMfW/4CDFingAuh1D0W+FFdt2z5vAhDZ87
 VNNuTAXLIH4k+gy4xckKkfSIpxkwTgvYsMJtVwD2CpT3I2z7WUsx7yhD+RTIKvalni79
 7FzlT+2ntxe2yLfX7kSwRx0BwVkX9n2pfaJudMxA01m3auB5MCJhtAjq0yb217qtkmMB
 w/YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=B4X35+dCh66GLhjJLrDaEmWkU4PBMcqZb4KydkQDfPI=;
 b=mqOGJr3ChOE0tpGIANqH6MDPWAj3j/pXGYVBuPMVuCpT0QABi4NOcjvMqAgmmZ+ORh
 cVBxq0zheIceEOHVaWr4RXpV/sYtbtCIlyO9PG05cgRymrdtTBrsEKzNJ91j4m4FdkWR
 bieRSWUIZfj2Y8zcJYkmNVfXSO5XIPh4/FfiSbq0QYvXbdhe/TL8hCeXIev1J1xD/QmC
 BcFuHBb3RmTf43a6mCQ5vREdMn+Uf+cNdzqQqpjy+8OqWv1fj3k7PdGNHR4xjNRkVtIJ
 6Ze9n22h5ZU0/vifWQmOgbu31kuxuKfSnri41Ka/tFOb26/aLA79KxmmacvxQUIQ4dP0
 ZFwQ==
X-Gm-Message-State: AOAM531JLN5rWfyAgYZSDd7fOvrY7Gw89SlYliAzBNYc5RVvXi2S2XDn
 QBTzfquRTMvtbLqnMZHIHWO45E/5fb42tiRB850=
X-Google-Smtp-Source: ABdhPJz2othmtOzyrP81+hZ5Cta/xJ0N43poJ7XsA2YWAcI717AwZwz2ESDsaC8u4aBPmR/hTATtPSTHExGIn3mzqTk=
X-Received: by 2002:a9d:269:: with SMTP id 96mr19220077otb.174.1607953476769; 
 Mon, 14 Dec 2020 05:44:36 -0800 (PST)
MIME-Version: 1.0
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
In-Reply-To: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Mon, 14 Dec 2020 14:44:25 +0100
Message-ID: <CAArVCkT0bA+5tqgMZrf1-cuenZi0v2mwY=LLZDXPJbRjtKFCuw@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Am Mo., 14. Dez. 2020 um 12:12 Uhr schrieb Mattias Engdeg=C3=A5rd <mattiase=
@acm.org>:
>
> > The sandboxing technologies I'm aware of are process-based (because Lin=
ux namespaces and kernel syscall filters are per-process), so a "start sand=
box from here" function likely can't be implemented. The interface should r=
ather be something like
>
> If you mean that the sandbox needs to be active from the very start of th=
e process, I don't see why that has to be the case. It does not appear to b=
e necessary for macOS, OpenBSD or FreeBSD, nor for at least some the Linux =
options I'm aware of.

Yes, it's not strictly required (as in, seccomp and unshare nominally
work at any point), though I think enabling sandboxing while user code
has already run can have confusing/unanticipated consequences. For
example, other threads might already be running in parallel, and they
would then suddenly be blocked from making some syscalls, potentially
in the middle of a critical section or similar. I'd expect that
there's lots of code around that doesn't expect syscalls to suddenly
start failing. Other sandboxing technologies like unsharing the user
namespace also don't work in multithreaded processes. Allowing
sandboxing (at least for now) only at process startup avoids such
issues and should be good enough for the given use case (Flymake
background compilation), since we need to start a new process anyway.

>
> Perhaps I misunderstood, and there may indeed be some desirable sandboxin=
g methods that require from-exec sandboxing. It is often useful to allow fo=
r a set-up period prior to activating restrictions allowing for specific fi=
les to be opened and so on and can make the sandboxing itself simpler by be=
ing less selective.

That is true, though it would require more significant changes to
Emacs. For example, to achieve some amount of capability-based
security, you'd open files before sandboxing and then forbid the open
syscall, but that's not really possible with the current Emacs API
(which doesn't provide any access to open files).

>
> From-exec sandboxing also precludes using simple forking (without exec) a=
s a cheap way to start the Emacs subprocess (if somewhat Unix-specific).
>

Even on Unix, a fork that's not immediately followed by an exec or
exit tends to not work any more. Lots of libraries nowadays assume
that the "weird in-between state" after a fork doesn't exist
permanently, and only a small number of async-signal-safe syscalls are
guaranteed to work between fork and exec.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 14 Dec 2020 11:12:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 14 06:12:51 2020
Received: from localhost ([127.0.0.1]:51391 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kolmc-00007K-Vo
	for submit <at> debbugs.gnu.org; Mon, 14 Dec 2020 06:12:51 -0500
Received: from mail18c50.megamailservers.eu ([91.136.10.28]:54854)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1kolma-00007A-DL
 for 45198 <at> debbugs.gnu.org; Mon, 14 Dec 2020 06:12:49 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1607944367;
 bh=ngYX7L/8giwQ54bAcIyibDNv6x9topyigBIDb/7HlhY=;
 h=From:Subject:Date:Cc:To:From;
 b=KA1digJZZwMqRQ7HOZ4V3wUxYosFec9PCEpC3ejmadH6N7OP56T5rOiiY/H/XPHrx
 pDpykYrjXZZ960FQOE3vDxWaUq5d7yFout+OnuZq3Ctm0nbykHHT0+BQ9K9tAkrYWB
 o5nLGZg0qTE41SD5baeCKNneKQD+iyEKDPKUJCoQ=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se
 [188.150.171.71]) (authenticated bits=0)
 by mail18c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BEBCiaD031132; 
 Mon, 14 Dec 2020 11:12:45 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-Id: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@HIDDEN>
Date: Mon, 14 Dec 2020 12:12:43 +0100
To: Philipp Stephani <p.stephani2@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A782F29.5FD748AE.00D9, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=e5N4tph/ c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117
 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=YIQCrXZNxxJIYbJI_LoA:9 a=CjuIK1q_8ugA:10
X-Origin-Country: SE
X-Spam-Score: 4.1 (++++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: > The sandboxing technologies I'm aware of are process-based
 (because Linux namespaces and kernel syscall filters are per-process), so
 a "start sandbox from here" function likely can't be implemented. [...] 
 Content analysis details:   (4.1 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 3.1 FAKE_REPLY_B           No description available.
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Monnier <monnier@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 3.1 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > The sandboxing technologies I'm aware of are process-based
    (because Linux namespaces and kernel syscall filters are per-process), so
    a "start sandbox from here" function likely can't be implemented. [...] 
 
 Content analysis details:   (3.1 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
  3.1 FAKE_REPLY_B           No description available.

> The sandboxing technologies I'm aware of are process-based (because =
Linux namespaces and kernel syscall filters are per-process), so a =
"start sandbox from here" function likely can't be implemented. The =
interface should rather be something like=20

If you mean that the sandbox needs to be active from the very start of =
the process, I don't see why that has to be the case. It does not appear =
to be necessary for macOS, OpenBSD or FreeBSD, nor for at least some the =
Linux options I'm aware of.

Perhaps I misunderstood, and there may indeed be some desirable =
sandboxing methods that require from-exec sandboxing. It is often useful =
to allow for a set-up period prior to activating restrictions allowing =
for specific files to be opened and so on and can make the sandboxing =
itself simpler by being less selective.

From-exec sandboxing also precludes using simple forking (without exec) =
as a cheap way to start the Emacs subprocess (if somewhat =
Unix-specific).





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 14 Dec 2020 11:05:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 14 06:05:28 2020
Received: from localhost ([127.0.0.1]:51377 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kolfT-0008Nc-Tl
	for submit <at> debbugs.gnu.org; Mon, 14 Dec 2020 06:05:28 -0500
Received: from mail-oi1-f170.google.com ([209.85.167.170]:42646)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kolfR-0008NP-W2
 for 45198 <at> debbugs.gnu.org; Mon, 14 Dec 2020 06:05:26 -0500
Received: by mail-oi1-f170.google.com with SMTP id l200so18732901oig.9
 for <45198 <at> debbugs.gnu.org>; Mon, 14 Dec 2020 03:05:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=0UeIQSmyHCrfPbxPyKyCUMo/yT6Jplt4z6y+Ji8Bv5Y=;
 b=kxUDZ3eI3ypRjUGdb84Iw6KM6PnCEwpUtIKlN8SA8YSPg1SbvwcdjwuqjS7P+PlJ9j
 yaXNn3nTmRsNLSHQY/1B8TfR7uXonFa1Khw3MnBaEl+M057MCOZtQoP8GvNPFFHo+k9S
 AAcvgjUjwWvC9x8o6pOtrAvcst/C1dpIxkrjyUyJhUGmHN95mOPXq3Fc5+Nbi99uHlnC
 VtGHp55my4oKirtgaQ3j5GFmJzGsjiUnI9P/l31bwcxq7SeUa6NcTPLNx8I1F/HW+KFP
 RX3yLFWC4AqkwBKJTXrmMhelwx6PbU8bsIl0ZKQ/GYrQelsYNbM391CurOH956Wl5QwQ
 h6fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=0UeIQSmyHCrfPbxPyKyCUMo/yT6Jplt4z6y+Ji8Bv5Y=;
 b=sTF9cfTCxlpq976+9kHXTz6tAQoY7FNytx1sZU+w02OkH1RkQicgcsFZFAIGulxNvt
 zchEQiE2vImNhEKRigh5JEjACFVjwyd77Eg9Z7lsjM3pEJyYiwJJBZp8RQXHvCaDpuZP
 k6cuZstPdK6LQWA/BIY5Wy4d9AmOGzudMpWAO5rUgomrUBQaq8xfYwOeeHi1YVEM9/b7
 pE38I9IV+DUxjqZusiCceuOnfeySjvRVHVBQCNkLmN99fBuQtMmtSYf2P3tvOWJKIIdo
 zPkaUCTNE5PKRLvWWhKFNeOUSzRStHlA4WakKCqX4Al9tGtdB7S/is/Xqm8fHLeFPvBw
 KBLw==
X-Gm-Message-State: AOAM531vauqIeKsoPqyWlwAPrIJEOp8k+gWd13L0nE6ldZKdx/N/G3Mg
 qCBxDMpwZrA8lw9vu6nn+g7N2U9gZRAaV1T+eRU=
X-Google-Smtp-Source: ABdhPJyZcpuph/6k3Ty2LjKLFYtAU6xRpWrmdPAbuxDmwQWRDNf+WZFyLK9FpM/NlEmbWb9iSi9wSkvxTVgnJdKq/oc=
X-Received: by 2002:aca:3a02:: with SMTP id h2mr17041529oia.65.1607943920185; 
 Mon, 14 Dec 2020 03:05:20 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Mon, 14 Dec 2020 12:05:09 +0100
Message-ID: <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Am So., 13. Dez. 2020 um 19:43 Uhr schrieb Stefan Monnier
<monnier@HIDDEN>:
>
> > The sandboxing technologies I'm aware of are process-based (because
> > Linux namespaces and kernel syscall filters are per-process), so a
> > "start sandbox from here" function likely can't be implemented. The
> > interface should rather be something like
> >
> > (defun run-in-sandbox (form)
> >   (eql 0 (call-process "bwrap" ... "emacs" "--quick" "--batch" (format
> > "--eval=%S" form))))
> >
> > (Maybe with some async variant and the opportunity to return some
> > result, like emacs-async.)
>
> Thanks.  We definitely want some output, otherwise there's no point in
> running `form`, right?

In some way certainly, but it's not necessarily through stdout. I tend
to write potential output into a file whose filename is passed on the
command line. That's more robust than stdout (which often contains
spurious messages about loading files etc.).

>
> Also, I think the async option is the most important one.  How 'bout:
>
>     (sandbox-start FUNCTION)
>
>     Lunch a sandboxed Emacs subprocess running FUNCTION.

Passing a function here might be confusing because e.g. lexical
closures won't work. It might be preferable to pass a form and state
that both dynamic and lexical bindings are ignored.

>     Returns a process object.

Depending how much we care about forward compatibility, it might be
better to return an opaque sandbox object (which will initially wrap a
process object).

>     FUNCTION is called with no arguments and it can use `sandbox-read`
>     to read the data sent to the process object via `process-send-string`,
>     and `sandbox-reply` to send back a reply to the parent process
>     (which will receive it via its `process-filter`).

That is, sandbox-read and sandbox-reply just read/write stdin/stdout?
That would certainly work, but (a) it doesn't really have anything to
do with sandboxing, so these functions should rather be called
stdin-read and stdout-write or similar, and (b) especially in the
stdout case might be too brittle because Emacs likes to print
arbitrary stuff on stdout/stderr.
Alternatively, the sandbox could use dedicated files or pipes to communicate.

>     The sandboxed process has read access to all the local files
>     but no write access to them, nor any access to the network or
>     the display.

This might be a bit too specific. I'd imagine we'd want to restrict
reading files to the absolute minimum (files that Emacs itself needs
plus a fixed set of input files/directories known in advance), but
often allow writing some output files.

>
> WDYT?

I think the interface is mostly OK, but I think we want to restrict
the set of allowed input/output files.

>
> >> - I suspect we'll still want to use the extra "manual" checks I put in
> >>   my code (so as to get clean ELisp errors when bumping against the
> >>   walls of the sandbox, and because of the added in-depth security).
> > That's reasonable, though I'm worried that it will give users a false
> > sense of security.
>
> That would only be the case if we don't additionally use process-level
> isolation, right?

My worry is that people see a function like enter-sandbox and then
assume that Emacs will be secure after calling it, without actually
verifying the security implications.

>
> >> - This will need someone else doing the implementation.
> > Looks like we already have a volunteer for macOS.
> > For Linux, this shouldn't be that difficult either. The sandbox needs
> > to install a mount namespace that only allows read access to Emacs's
> > installation directory plus any input file and write access to known
> > output files, and enable syscall filters that forbid everything except
> > a list of known-safe syscalls (especially exec). I can take a stab at
> > that, but I can't promise anything ;-)
>
> Looking forward to it.
>

I've looked into this, and what I'd suggest for now is:
1. Add a --seccomp=FILE command-line option that loads seccomp filters
from FILE and applies them directly after startup (first thing in
main). Why do this in Emacs? Because that's the easiest way to prevent
execve. When installing a seccomp filter in a separate process, execve
needs to be allowed because otherwise there'd be no way to execute the
Emacs binary. While there are workarounds (ptrace, LD_PRELOAD), it's
easiest to install the seccomp filter directly in the Emacs process.
2. Generate appropriate seccomp filters using libseccomp or similar.
3. In the sandboxing functions, start Emacs with bwrap to set up
namespaces and invoke Emacs with the new --seccomp flag.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 20:13:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 15:13:27 2020
Received: from localhost ([127.0.0.1]:50431 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koXkF-0002bp-Cu
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 15:13:27 -0500
Received: from mail-wm1-f47.google.com ([209.85.128.47]:52879)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1koXkD-0002bL-Vy
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 15:13:26 -0500
Received: by mail-wm1-f47.google.com with SMTP id a6so11942615wmc.2
 for <45198 <at> debbugs.gnu.org>; Sun, 13 Dec 2020 12:13:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=LlgXtqBosNWZ5pp6vxtg+Lx374NQLUhAsVtUsFfZ8kU=;
 b=P32Z1JMhWCSRkVDKSIN1y69TE85ewNMhWKIT6egGgWTRUk57LOX/+s0mZK2q91qtZM
 96+V0M/E110RARy0H8dOFdDUF2oRzbT+MrqEy1PWpt2ehnsJ2GdgUi4opQogbJNuunpd
 uHCCXL1lB5w5XzPpiIF16GV8uLyO66WAGbT6Xz+x4lWL0oBHgVfoabVAy5hiY1eRKJXB
 Pprn5sAmEzCjEwfiC8Kx2e9FCk520S8FaATlnmgQTnr+ah8zRs3ZPhuoQSAJB+SZpA6g
 LaL44E6PIVh4PcHtaOj7ib3LRM6gL1PUCwck/Foog7WttkgE1O5g8fKnugAIm1g1nJlo
 4E+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=LlgXtqBosNWZ5pp6vxtg+Lx374NQLUhAsVtUsFfZ8kU=;
 b=bY4Z0kHCLjjO4ijVygtQP5KiZdHpB2VbyVpZ+Vmnnw9m7CpfcrvUxZ3JFmZu8Ebl5Y
 TkCoos+GWc5fH+HhPOfh37Bi0gFKzmgj6nR4uQnIJuu8SaF0BuW8m3yKsci+soc/B6Ln
 3zc3pzsInOxH2LLC3WF0XEgRlT9ZcudUD3tc9j6QNQd+IzSGluTG/liJNg/uwMZwjc4m
 PRSQr+jmZzBpp5YBVHORd4cdlLti08LYeiVg2YuG7IxEQQRtlsV/TAiVzb7tcMvU8vSv
 R/nfcq9A8GpZpdAUyJoEWm5+9XrV5ILHqEz7Y76ZNI4ekPH3zJw0tnc9AVj4UeyI1mah
 p2vw==
X-Gm-Message-State: AOAM532QXROWgNGPLXegqr+8wJCAYlpOUkHVJJLBGl0hV0WF2mBb1x/6
 Se9vd86PNtt+8o4yCQDiSS4=
X-Google-Smtp-Source: ABdhPJzwxw/8OH4lYs/5i2fdCegAGrCIhEQ2taZPnZaPmvEkPhtk7Hn1idNjVya0mzhD8Q7triF1eg==
X-Received: by 2002:a1c:c2d4:: with SMTP id s203mr24397477wmf.58.1607890400186; 
 Sun, 13 Dec 2020 12:13:20 -0800 (PST)
Received: from krug (a94-133-30-26.cpe.netcabo.pt. [94.133.30.26])
 by smtp.gmail.com with ESMTPSA id g184sm28655499wma.16.2020.12.13.12.13.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 13 Dec 2020 12:13:18 -0800 (PST)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
Date: Sun, 13 Dec 2020 20:13:16 +0000
In-Reply-To: <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Sun, 13 Dec 2020 12:57:25 -0500")
Message-ID: <87mtyhzcpv.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, Philipp Stephani <p.stephani2@HIDDEN>,
 45198 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Stefan Monnier <monnier@HIDDEN> writes:

>> I don't think such an approach can work. It assumes perfect knowledge
>> about anything that might be problematic, and also assumes that all
>> future changes to Emacs take the sandbox question into account.
>> Especially the latter point seems unrealistic, and this looks like a
>> security incident waiting to happen.
>
> That's true for the implementation side.
> How 'bout the ELisp API side?

That's well pointed out.  Why can't we just put the gate in the default
expansion of the C DEFUN macro?  There are only so many DEFUN's.  Then
the whitelisting could proceed from there.  DEFUN's are rarely added,
and they would be forbidden in sandbox mode by default.

Jo=C3=A3o





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 18:52:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 13:52:39 2020
Received: from localhost ([127.0.0.1]:50240 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koWU2-0004zd-Qp
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 13:52:39 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60785)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1koWU1-0004z7-IF
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 13:52:37 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 31BB71002B8;
 Sun, 13 Dec 2020 13:52:32 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C915210022E;
 Sun, 13 Dec 2020 13:52:30 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1607885550;
 bh=PkQpsSNyVdM8Q1VaNpSJCtrQuRhx0REwuCPfsAm56yE=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=AjxEDBqBSiSU90839OYhS4fIuuTOm2Spn2SjsxoXeyM5PLebZPlWvQZvfJoFEGATn
 NP+uEMB6dtc2KLzv6p3rH81fKM/FNiBjOFgquZ6aQCY0eJbgwZ+HJ3WO+1+ACngXre
 SZJsiXGRsvckbnXfKVFXPoQ5QkAbtUfWcCj/eAt6URReaPP4ulg5nELjppy0fed4Lp
 WOETizfbNc8Q4SJspggtIWuRDxXHnGhBDfwqyqz7JpfOlPCbnmuu9MNJwOhZQbxAew
 LFrXtJh3LOkYbTDSI4fw77KzKK+RZgCMR0QyAWB2SFJgZ7fxWmLh3gwIL9Sp/LKNxK
 rk4uwxSeOxCMg==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 853F11204C5;
 Sun, 13 Dec 2020 13:52:30 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwv7dplletm.fsf-monnier+emacs@HIDDEN>
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
Date: Sun, 13 Dec 2020 13:52:29 -0500
In-Reply-To: <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 (Philipp Stephani's message of "Sun, 13 Dec 2020 19:13:35 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.079 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?windows-1252?B?Sm/j?= =?windows-1252?B?byBU4XZvcmE=?=
 <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>   (eql 0 (call-process "bwrap" ... "emacs" "--quick" "--batch" (format
> "--eval=%S" form))))

BTW, thanks for this reference to bwrap.  It looks like I should be able
to use it for my immediate needs in (Non)GNU ELPA scripting.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 18:43:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 13:43:34 2020
Received: from localhost ([127.0.0.1]:50224 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koWLF-0004Ix-Tc
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 13:43:34 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63231)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1koWLE-0004IP-8H
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 13:43:32 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D6D641002B8;
 Sun, 13 Dec 2020 13:43:26 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6947C10022E;
 Sun, 13 Dec 2020 13:43:25 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1607885005;
 bh=xma7jsPMN6c+gzRTJjPnZi/Z+lobwPlxFNDfwpnAYIE=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=AoHI0YtnbrZE+Y8lAPturHtvCCKTwq4w2e/wQyxpDSliGKUPyIQ/boigPNs7B+ZY6
 02XEuID8/7PT3n+kqOHVh8WvYYxbqdQiKiRUgNsAmtmhbhIrUPyTi3tWeMtlQTngAl
 C4ztmqX4hVnvo5iDWLJIYxQp7NxA9Z4h1t2joFbYCat8n2UDPPvODY1qjrhWXDRYru
 AKUU/S58N8MTk+LeUaF17pGuiRW0llAaTx9Ouu9/EMfI2nXMjmY7rPmfLo/9P6NHOe
 zdsGzJs/d6Is/JMyGKZtIoNY/1sMdY1YGK7RG2nnNl2W54czUXH68eAbmnkoGdT6fi
 F8Ass7hTXyuCA==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 261321201B2;
 Sun, 13 Dec 2020 13:43:25 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwvczzdlfws.fsf-monnier+emacs@HIDDEN>
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
 <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
Date: Sun, 13 Dec 2020 13:43:23 -0500
In-Reply-To: <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
 (Philipp Stephani's message of "Sun, 13 Dec 2020 19:13:35 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.079 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?windows-1252?B?Sm/j?= =?windows-1252?B?byBU4XZvcmE=?=
 <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> The sandboxing technologies I'm aware of are process-based (because
> Linux namespaces and kernel syscall filters are per-process), so a
> "start sandbox from here" function likely can't be implemented. The
> interface should rather be something like
>
> (defun run-in-sandbox (form)
>   (eql 0 (call-process "bwrap" ... "emacs" "--quick" "--batch" (format
> "--eval=%S" form))))
>
> (Maybe with some async variant and the opportunity to return some
> result, like emacs-async.)

Thanks.  We definitely want some output, otherwise there's no point in
running `form`, right?

Also, I think the async option is the most important one.  How 'bout:

    (sandbox-start FUNCTION)

    Lunch a sandboxed Emacs subprocess running FUNCTION.
    Returns a process object.
    FUNCTION is called with no arguments and it can use `sandbox-read`
    to read the data sent to the process object via `process-send-string`,
    and `sandbox-reply` to send back a reply to the parent process
    (which will receive it via its `process-filter`).
    The sandboxed process has read access to all the local files
    but no write access to them, nor any access to the network or
    the display.

WDYT?

>> - I suspect we'll still want to use the extra "manual" checks I put in
>>   my code (so as to get clean ELisp errors when bumping against the
>>   walls of the sandbox, and because of the added in-depth security).
> That's reasonable, though I'm worried that it will give users a false
> sense of security.

That would only be the case if we don't additionally use process-level
isolation, right?

>> - This will need someone else doing the implementation.
> Looks like we already have a volunteer for macOS.
> For Linux, this shouldn't be that difficult either. The sandbox needs
> to install a mount namespace that only allows read access to Emacs's
> installation directory plus any input file and write access to known
> output files, and enable syscall filters that forbid everything except
> a list of known-safe syscalls (especially exec). I can take a stab at
> that, but I can't promise anything ;-)

Looking forward to it.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 18:13:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 13:13:55 2020
Received: from localhost ([127.0.0.1]:50089 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koVsY-0002qF-Pq
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 13:13:55 -0500
Received: from mail-oi1-f169.google.com ([209.85.167.169]:36982)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1koVsW-0002py-Oe
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 13:13:53 -0500
Received: by mail-oi1-f169.google.com with SMTP id l207so16639372oib.4
 for <45198 <at> debbugs.gnu.org>; Sun, 13 Dec 2020 10:13:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=3Cg8XRaYwrmO/GiGsv6IskmDMoQI/lXKAvuiN1wSDmY=;
 b=P8X4NW5GW9x0CQKsfjDy6upTde9B4yIgaZj8PuDsgQhF2jM/HwGy/ymqjWBLRpy9lK
 tNMhLv9RyCi/7nOVmlyGAn2lZGeBBeiQ8Q5QvHokp/8YfrcLARN0Wser1dyyHepgqO8h
 L7s2byBmAc3sbi16XICTogP9452/dDfmdXO0fxz/z/JzUpxUmsrLN9D+t3irPXndMs02
 VkJI24I9EnBWxaZK/B7smGNXfsZy9WVh9Ui5iPTcMcdAo73hJfbhCQqbnsoVDEwbJ9/l
 bOFaRq3rcD9L7TOKSCOozSQ+jarTFjETP+4qIQgf7dYaYw5Ikgcv+ErAr2ghRGR6zOAG
 T6wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=3Cg8XRaYwrmO/GiGsv6IskmDMoQI/lXKAvuiN1wSDmY=;
 b=RdE4MEjDg2gTjx7mdwjv4eKFYRfFq4GQCJtXcjLsFTo9pufQhlVPICfxL7sO4Fd4CC
 9ZD6dSSX6B0yBe4Mmpy3yQzNsHS/r2dd38/ucZ8HyGolmZ9xM7RPYAFQod/PgtHZkbqc
 GzSZlhIMQJ1swW+nZc2v/csw4wS45eN9f97UtFCI3qIsJVg5MzyVNdVSIWGaMyY26qBt
 c5rSBgH1waStghmKFuCMlYetUcO3aZj+3tgoDwt0YkCcsLM1e59qngbtJoiEj9c5IelI
 4KDGpRtDWlZUGX4zfkhvktTu53XqYWJJ4g8vOkQ01+l3fSCfIxC3gUPxQefSFbaEur8K
 scYw==
X-Gm-Message-State: AOAM5337ZCVwOIax9pVyO75fhK4o6xTMyWYUx7FjCT1pkar2KtSQXJyI
 11cXHr8rmnmBqiT/DlTAMrkCasHk6ORoRY6jp3Q=
X-Google-Smtp-Source: ABdhPJy0g4gyq9R9Sc9NCObwJEbqU2dd/xeHPuu1dV4eqM5aMEZYgTCzjfrUTMUwyDOgRmmVMJOATLnzRpnEFU6DwrA=
X-Received: by 2002:a54:4881:: with SMTP id r1mr15576450oic.9.1607883227036;
 Sun, 13 Dec 2020 10:13:47 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sun, 13 Dec 2020 19:13:35 +0100
Message-ID: <CAArVCkSJmVAsrKwLMVtVhamW=Py5NhgSoc+1pZ+Cn=cq5PjLUg@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Am So., 13. Dez. 2020 um 18:57 Uhr schrieb Stefan Monnier
<monnier@HIDDEN>:
>
> > I don't think such an approach can work. It assumes perfect knowledge
> > about anything that might be problematic, and also assumes that all
> > future changes to Emacs take the sandbox question into account.
> > Especially the latter point seems unrealistic, and this looks like a
> > security incident waiting to happen.
>
> That's true for the implementation side.
> How 'bout the ELisp API side?
>
> > Sandboxing is good, but it should happen using an allowlist and
> > established technology, such as firejail/bubblewrap/Google sandboxed
> > API/...

The sandboxing technologies I'm aware of are process-based (because
Linux namespaces and kernel syscall filters are per-process), so a
"start sandbox from here" function likely can't be implemented. The
interface should rather be something like

(defun run-in-sandbox (form)
  (eql 0 (call-process "bwrap" ... "emacs" "--quick" "--batch" (format
"--eval=%S" form))))

(Maybe with some async variant and the opportunity to return some
result, like emacs-async.)

>
> I'm all for it, *but*:
> - I suspect we'll still want to use the extra "manual" checks I put in
>   my code (so as to get clean ELisp errors when bumping against the
>   walls of the sandbox, and because of the added in-depth security).

That's reasonable, though I'm worried that it will give users a false
sense of security.

> - This will need someone else doing the implementation.

Looks like we already have a volunteer for macOS.
For Linux, this shouldn't be that difficult either. The sandbox needs
to install a mount namespace that only allows read access to Emacs's
installation directory plus any input file and write access to known
output files, and enable syscall filters that forbid everything except
a list of known-safe syscalls (especially exec). I can take a stab at
that, but I can't promise anything ;-)

> - The ELisp-level API should not depend on the specific implementation
>   too much, since none of those established technologies sound like
>   things that'll still be maintained 10 years from now.

Yes, I'd imagine the API to be something like

;; Returns an opaque "sandbox" object.
(cl-defun start-sandbox (form &key input-files output-files) ...)
(defun wait-for-sandbox (sandbox) ...)
That would allow for some extensibility and also asynchronicity. The
API should fail if it can't establish a sandbox (e.g. if none of the
sandbox technologies are installed).

> - We need to have this in Emacs-28 if we want to enable flymake-mode in
>   ELisp by default in Emacs-28 (which I sure would like to do).

I guess having it in Emacs 28 is realistic, unless that is going to be
feature-frozen soon.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 17:57:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 12:57:34 2020
Received: from localhost ([127.0.0.1]:50056 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koVck-0002Q8-KX
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:57:34 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39346)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1koVcj-0002Px-Ia
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:57:33 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3AE8480625;
 Sun, 13 Dec 2020 12:57:28 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DF7808033C;
 Sun, 13 Dec 2020 12:57:26 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1607882246;
 bh=dCv+MUQWh7xnVsUU0jVfIP+QBCBZW/40jZ8hVV+4NE0=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=Fzo8n9064wliUTVh43OVxo1AZe4OXzkjEc4Vik9PinY7LwUe9K189jXFxNIU4/gYX
 AJvJq4CD0JqhhcbvTDTUJPHYCoIU5WWcX3XKtqdI68A+XWVtDjt0iBl3XVVNVPUl9H
 1Hj03MUQuec3mWrCzBqzOMvHVAKLc0HE/t8fju6h9symzbjiEbXNi70AdjyaQgMxZC
 mj7VV/hj7V+ciesnrzEGA2y5riZlhEhW79QB82X+efXLGMHLmOB1ltStK5LsT0khbG
 NTA1QLKjJv5N4PFQhARS1ia+NCRZyyB8247I0W73lcs1wHmdYWclpctVhKLEItM3ut
 zpZASFM42CybA==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9DB53120392;
 Sun, 13 Dec 2020 12:57:26 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwvo8ixlhv9.fsf-monnier+emacs@HIDDEN>
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
Date: Sun, 13 Dec 2020 12:57:25 -0500
In-Reply-To: <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
 (Philipp Stephani's message of "Sun, 13 Dec 2020 18:04:52 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.060 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?windows-1252?B?Sm/j?= =?windows-1252?B?byBU4XZvcmE=?=
 <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> I don't think such an approach can work. It assumes perfect knowledge
> about anything that might be problematic, and also assumes that all
> future changes to Emacs take the sandbox question into account.
> Especially the latter point seems unrealistic, and this looks like a
> security incident waiting to happen.

That's true for the implementation side.
How 'bout the ELisp API side?

> Sandboxing is good, but it should happen using an allowlist and
> established technology, such as firejail/bubblewrap/Google sandboxed
> API/...

I'm all for it, *but*:
- I suspect we'll still want to use the extra "manual" checks I put in
  my code (so as to get clean ELisp errors when bumping against the
  walls of the sandbox, and because of the added in-depth security).
- This will need someone else doing the implementation.
- The ELisp-level API should not depend on the specific implementation
  too much, since none of those established technologies sound like
  things that'll still be maintained 10 years from now.
- We need to have this in Emacs-28 if we want to enable flymake-mode in
  ELisp by default in Emacs-28 (which I sure would like to do).
- I'd like to have this yesterday in order to build the Info files of
  GNU&NonGNU ELPA packages from their .org documentation without having
  to store the Info in the Git branch nor having to maintain some LXC
  container just for that.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 17:09:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 12:09:55 2020
Received: from localhost ([127.0.0.1]:49992 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koUsW-000183-0K
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:09:55 -0500
Received: from mail-oi1-f182.google.com ([209.85.167.182]:46843)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1koUsU-00017r-9D
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:09:46 -0500
Received: by mail-oi1-f182.google.com with SMTP id q205so3751053oig.13
 for <45198 <at> debbugs.gnu.org>; Sun, 13 Dec 2020 09:09:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=Mn8E/T+QIfpNdyfF/XgD03yfFvBOkwcEFmSl8V3Ztvk=;
 b=ObrS7i/Ka4b9AkmZcKdEIw6auWTjZ/Q/Bn80iTVWPtJ6dB1B+GLAATaOLBRazjQO8+
 WQNZNMxtkyNuq8N+Ak0PmBatVvZllHRbbtZFdsJjVq9q1gR8u+/WlRfoGv1JBHxQcqEq
 uX6i7UAzyZMlYeR0NRytyhSi9zAU8JQ4gUtmMg10mzlyINDChqWomK1v4W6YzZtkBUvE
 Eld8rmIZyBq+FGHPGecuH+77tM4TFp5YXzeyts/ho94pV7/qL+Mvmx9IfDUIsAhuoeTe
 ZY6APbS8Qbl13y3fUV5/Sof2ftE+XBeIsSO1r52sYO6hUHOBpwQKXazVaauhv3QyqWMh
 DZDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=Mn8E/T+QIfpNdyfF/XgD03yfFvBOkwcEFmSl8V3Ztvk=;
 b=tlccKhwmHzMx4Bd2NnQMy4BBq+Wq92iJDXgUPBAW7dZg3Ok5zBwzsxIkU+AeCHHl70
 5NvKW3E38r5txQr3T7msNRNUVmq8pfbJx0pzzq4cshn8ydDyq2csv8ePh1+KntSnFW0l
 hjhXmb2gvyadPs+K/kDyYPNvoyg/0Hfdl4gWuasXTZCnLzZEmBAwImIN4wjqW7gd+pSS
 SeAfCsFaPC/vUlAbOTHdrD0ttErNtrDMS5YFFAcdJyRDy1h56vWLFqrrg8zeT0MB7sMN
 PlC5l0rLbAvnkOW/4v+hEvik7wTpbYWA5GffOWeB2bxxO6/NOuot2S2bm+nuTxDwGPVM
 5O9w==
X-Gm-Message-State: AOAM532bh6YOVHYkGycXg9+OrISX4syKnAf9o7CVnRAnt9BGM68XphYw
 dGLOpAFb0An6FoYNQxx5b5aL3pT/XTdfskScTkU=
X-Google-Smtp-Source: ABdhPJxAfM06tBzrzApYFLa4DQNJ3WHeMa8zdduitrEDueX0ZCl4ABs5XEGmAzCknBvWQhR7L627uxI1+feNmugMZdo=
X-Received: by 2002:aca:d4cf:: with SMTP id
 l198mr15702352oig.170.1607879380832; 
 Sun, 13 Dec 2020 09:09:40 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
 <B6C702AA-0850-48EF-87C7-C48D05270454@HIDDEN>
In-Reply-To: <B6C702AA-0850-48EF-87C7-C48D05270454@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sun, 13 Dec 2020 18:09:29 +0100
Message-ID: <CAArVCkSZXgLmeGKYxu3OkhDT_ksoQhcMzTbJLiCeSbdvznFKcg@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Am So., 13. Dez. 2020 um 16:32 Uhr schrieb Mattias Engdeg=C3=A5rd <mattiase=
@acm.org>:

>  For Linux there are several options, most a bit messy but possible to us=
e: seccomp (with or without BFP), name spaces, ptrace, etc.


Fortunately there are quite a few good wrappers for these: firejail,
bubblewrap, nsjail, minijail, Google Sandbox2.
https://developers.google.com/sandboxed-api/docs/sandbox-overview has
a good overview.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 17:07:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 12:07:51 2020
Received: from localhost ([127.0.0.1]:49988 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koUqd-000158-MH
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:07:51 -0500
Received: from mail-oi1-f177.google.com ([209.85.167.177]:44323)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1koUqc-00014v-2G
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:07:50 -0500
Received: by mail-oi1-f177.google.com with SMTP id d189so16462206oig.11
 for <45198 <at> debbugs.gnu.org>; Sun, 13 Dec 2020 09:07:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Zhz4+259vRsoBnwqiE+S1oDW+R153YFP6gG04Nzd2k4=;
 b=uEM5X3TJjoGDmMN8gKPqhEXFm03P2AMoFGNjAOftNhXTBxqeuC+9cqqdVgOhbbQhP1
 PRnec79OeR94KNn1kibPfwueDIy9/rWR/4GE77cWzDP4ZV9x711DlQsYn5H0CwbuSBnI
 hnGTbx/ij7AQAbc26qXc3OYirAas0+BUD6PuWB9f0y6bD38Ca34GbfcDeBeTqxzDD/oo
 BWKeVC1q/0m5fvj2RUXPkJUsBjvB8WKTKm/xl+OnOAvq0M/nAO/opK/0zk2G3nSpn/PU
 4eTpCuj0/Fgz1km2jsd0C3nGga8q5/2zKNEMBJSijh62uhqGzKSDX2plHxJKChoSclSH
 CXLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Zhz4+259vRsoBnwqiE+S1oDW+R153YFP6gG04Nzd2k4=;
 b=I1C2bHfqGbo8xxnYYSVUsorI6/iodTXd7twR+/WBDJwClElA6RJ9XreHIJfOJPTskj
 LyHf2U2ONz/rUqrfHJtM2/e/ArIlt0Y09G8BgyW4BL9bu2orr86Kguf+uEv2vOuptFbk
 3X7DVfisCpECVI+19nj2hy6GkHeWCLBa7ci3GI22jgWzxGwtdwkyG6JZD/N8cROzBVQc
 cSOP0KiAgitX3dAeNT0qXlyPRhQbT5VMd2+SCKRNU49SM3WomEQD0PoWbj8LMuGzpI6n
 hDwcTsgoh76gmdzSwhczdO53ZnRUeo/GOOK3cZ1463V9ElQiToeU04GY6r+jwjRYhbkR
 6DUA==
X-Gm-Message-State: AOAM532iDIoDJ/u5SkV46S6N9rU2IeAd4HYsoVsQvFwLzJOpHBaNozNJ
 eL3RbU6P8cq09RRrEZ5UyuD4iJiK7rZDt5LAyplYvSnw
X-Google-Smtp-Source: ABdhPJx7XkJguBDEVTh45+dcwxyUKerDpOTRwLMxiFXHl1WP44QGVhx2TVjMUTa55BHucOTOD76LgLIFu9P6PHN7pQ4=
X-Received: by 2002:a54:4881:: with SMTP id r1mr15462645oic.9.1607879264651;
 Sun, 13 Dec 2020 09:07:44 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN> <83mtyierfs.fsf@HIDDEN>
 <jwv360aohw6.fsf-monnier+emacs@HIDDEN> <83ft4ae63m.fsf@HIDDEN>
 <jwvlfe2mj6c.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvlfe2mj6c.fsf-monnier+emacs@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sun, 13 Dec 2020 18:07:33 +0100
Message-ID: <CAArVCkTi1yTH5=u58y_NZejTZwKegnCXOSX-ey6F7_jqgC1tgQ@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: bzg@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Am So., 13. Dez. 2020 um 05:26 Uhr schrieb Stefan Monnier
<monnier@HIDDEN>:
> I'm still worried that there remain wide open security holes, tho.

Yes, this is still essentially arbitrary RCE.
Running untrusted code needs defence in depth.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 17:05:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 12:05:11 2020
Received: from localhost ([127.0.0.1]:49984 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koUo3-00011T-9P
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:05:11 -0500
Received: from mail-oi1-f177.google.com ([209.85.167.177]:43159)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1koUo1-00011D-Bx
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:05:09 -0500
Received: by mail-oi1-f177.google.com with SMTP id q25so16463694oij.10
 for <45198 <at> debbugs.gnu.org>; Sun, 13 Dec 2020 09:05:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=yv8HURJP5ofanAtWAiTOAUvBAj8/6A3diiH33PL7QhM=;
 b=YiboP73DxtmsL50pDObS5FJvfEujCDnPSGybJd9TnfPfY08EnBw2kPH4HXLNlOjsir
 nKgCnYpuoMiUlWYiyIy4W4bX47N/B78n9S+zwsnEsX0p8Npb36eXaqadwHx+/LWfpzvD
 vqQGOsEQX2/i04K9MQ+wIMB2t8r6aESmQ5NV4FXwgrTXprEeuugp7VLna7n/Nq2jFeTi
 HNR9qv3dL0PbR4WTUSp1FbQ2Txy89EAaPdL5s9jciei4BNggEqlWe7GUv/Gy1jy2v35D
 4DUyvIzpEtkkfSN/OeugSbX+Cmvez3/zYpKdzObGNCOCo5GDJ8K9mA7KQ80QvTGAV+ez
 dl5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=yv8HURJP5ofanAtWAiTOAUvBAj8/6A3diiH33PL7QhM=;
 b=GICHeArc8Glky5B4sZ9dVH4v50+cGUZsPJ4bAArCoPc1loUPoOHTyoZgwHrsuHEcyH
 TrP0zeIcOvWkCZibHpdR2asmNEuZvv8ENArHmS4NiXtYGbhYb9J7S7ZQgQGPWTVnnSrS
 tI0jOv//sIM916A4ADGyuF0OU84V4+kfMpPgVpxtz1ydgkvbxYGWfw1Rdnbiw3CCT2Ty
 LdOt/IZgOc5u4DRZRp6CQiwK5ZBgOzSno+dN+5YZU5OWlJFm1STdAmmDIPSJe/ACnP04
 ywt6kpooscVivcwOl2QRLzgmzw0x4t6bnIMNIX3RaEUDb9O9sQtheluTu3/88XAlfmyw
 p32A==
X-Gm-Message-State: AOAM531CusgKzIeVDdpy5WvwvFup8uKSABh8n2fXAkOzdE2jLMs0GAbY
 /82iM5nEV8UkYN4Jm7YKsMACT2F57PlUZVtcFAI=
X-Google-Smtp-Source: ABdhPJxu/DsZnZfVw1h7tXm1lqAwbr2DR07o/YfzeAjOrtCcOOijmNRkv1zf4ZCJiPXyIcnHjScuUDZGvwS4JzFW9+o=
X-Received: by 2002:a54:4881:: with SMTP id r1mr15455959oic.9.1607879103627;
 Sun, 13 Dec 2020 09:05:03 -0800 (PST)
MIME-Version: 1.0
References: <jwvpn3ehpjz.fsf@HIDDEN>
In-Reply-To: <jwvpn3ehpjz.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sun, 13 Dec 2020 18:04:52 +0100
Message-ID: <CAArVCkSd9XjF1_18ovR3tBLyJejNsyhc4dSMx0XEWJwPMy85MA@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Am Sa., 12. Dez. 2020 um 20:40 Uhr schrieb Stefan Monnier
<monnier@HIDDEN>:
>
> One thing I'm particularly eager to hear your opinion about is whether
> there might be more holes to plug (i.e. more places where we need to
> call `ensure_no_sandbox`).  Clearly, from a security perspective, this is
> the main drawback of this approach: it's based on a black list rather
> than on a whitelist.  Still, I have the impression that it should
> be manageable.

I don't think such an approach can work. It assumes perfect knowledge
about anything that might be problematic, and also assumes that all
future changes to Emacs take the sandbox question into account.
Especially the latter point seems unrealistic, and this looks like a
security incident waiting to happen.
Sandboxing is good, but it should happen using an allowlist and
established technology, such as firejail/bubblewrap/Google sandboxed
API/...




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 15:31:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 10:31:11 2020
Received: from localhost ([127.0.0.1]:49936 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koTL5-0006i3-4P
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 10:31:11 -0500
Received: from mail18c50.megamailservers.eu ([91.136.10.28]:34764)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1koTKz-0006hb-V8
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 10:31:09 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1607873464;
 bh=oZeGC9xoLyjD8QpyxpakN05RkeMQKBSs4SQ1PaM44OY=;
 h=From:Subject:Date:Cc:To:From;
 b=sLvPUKXGZak308rvgEuR4VeFf2/JivM/XacxOPG7lyt0CLf/owWWSHlH3p73d77vF
 oYmtOx/qfGok2VMC/mWp42SvyvivCckY1kBFzukhguZe1DQrzzObRFW0cJaeRKlltm
 6zkq2r+usoeXq2+OIQ04YDpegXeAHl/KoHF5WctY=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se
 [188.150.171.71]) (authenticated bits=0)
 by mail18c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BDFV10c010992; 
 Sun, 13 Dec 2020 15:31:03 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-Id: <B6C702AA-0850-48EF-87C7-C48D05270454@HIDDEN>
Date: Sun, 13 Dec 2020 16:31:00 +0100
To: Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
 Bastien <bzg@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A782F19.5FD633B8.0020, ss=1, re=0.000, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.3 cv=e5N4tph/ c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117
 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=945-CkrjixCtq6tHtyUA:9 a=CjuIK1q_8ugA:10
X-Origin-Country: SE
X-Spam-Score: 4.1 (++++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: > I'm still worried that there remain wide open security
 holes, 
 tho. Yes, and we need defence in depth. In addition to the measures already
 taken in the patch: 1. Add crash_if_sandboxed() calls in low-level routines
 that do objectionable things such as opening files for writing, create network
 connections, spawn processes, do DNS lookups, etc. 
 Content analysis details:   (4.1 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 3.1 FAKE_REPLY_B           No description available.
X-Debbugs-Envelope-To: 45198
Cc: 45198 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 3.1 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > I'm still worried that there remain wide open security holes,
    tho. Yes, and we need defence in depth. In addition to the measures already
    taken in the patch: 1. Add crash_if_sandboxed() calls in low-level routines
    that do objectionable things such as opening files for writing, create network
    connections, spawn processes, do DNS lookups, etc. 
 
 Content analysis details:   (3.1 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
  3.1 FAKE_REPLY_B           No description available.

> I'm still worried that there remain wide open security holes, tho.

Yes, and we need defence in depth. In addition to the measures already =
taken in the patch:

1. Add crash_if_sandboxed() calls in low-level routines that do =
objectionable things such as opening files for writing, create network =
connections, spawn processes, do DNS lookups, etc.

2. Platform-specific restrictions. I'll add macOS sandboxing if nobody =
else does. For Linux there are several options, most a bit messy but =
possible to use: seccomp (with or without BFP), name spaces, ptrace, =
etc.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 11:15:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 06:15:04 2020
Received: from localhost ([127.0.0.1]:47508 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koPLD-0002W0-To
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 06:15:04 -0500
Received: from mail-wm1-f47.google.com ([209.85.128.47]:34981)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1koPLC-0002Ul-Bd
 for 45198 <at> debbugs.gnu.org; Sun, 13 Dec 2020 06:15:02 -0500
Received: by mail-wm1-f47.google.com with SMTP id e25so12636863wme.0
 for <45198 <at> debbugs.gnu.org>; Sun, 13 Dec 2020 03:15:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=0dFJ7REgDbDr/rzkxNYFIArDFiDosKqonAV8Sm2wWcE=;
 b=Gxm1CSkGayAmr6FPduOVE87OrVap+e7lIhjeNUeNxVI0Zm5NCMVPWTwZG+2f9PgJ1t
 opaU3850kaCdVjnI2ezrahAoO+wWmx3W4NIaneQ0lGEeiIihvU+6BKXLLyXzrwTxOFmO
 0FplnYCJiYe7XYCdmUGKL2fGPD6Mj3t2FOKj6w8xB1viE0oaThOEREv+CLzuw3zG0uOW
 26KPuEbpdep93Grjwt+0n3l3mrSxDMKJvToCi3vouKveJvVvANbOG+7eV818a0128OAl
 xTKNf7CeS/STX7hNCZ8MJqebOG+KGKFruY5PDbza4SCQwc5muU/mzlvuX1jZj1ft2hY5
 GjFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=0dFJ7REgDbDr/rzkxNYFIArDFiDosKqonAV8Sm2wWcE=;
 b=ARvSTyB0fwGx469lcEwrcWGA75qmBEZEjwJ3yaNAyw051Qvr9csnT4s1fmo9bVW9aK
 LmBOTwr66enX4eU6/7XJb8bZo6k5jY+A+0yeab+RdDIbGyjvhl+SD3UvVg/YlrKTIKg2
 ZLvbMPE7UoLQkkcy7BJ1mZStiSa+JhvbUm782gbyVy/uPC/QXG+LsXPEtbFammx6Xwmp
 Bp7DEoYMx+m3XCd7f9Tkc5Ahuk2XSYkagXS6AkUf22wBFI9g9+ZTsF4aWEZAmKvXe4ys
 LuzmQa4F7UFBlkznKfzAiuHdgMM3L/ZrPBKyMqkQN07INjS55UmgnvctHfF/PMgAsUWj
 UD/g==
X-Gm-Message-State: AOAM533HMZgzfBzQXKuIMYNIW3gRuJegOgovhqCFKmTUwZT6s3t5qaXF
 0I7RR8Ihga3knD4c0qy/4sTSVl5+H0s=
X-Google-Smtp-Source: ABdhPJyhUC7J9Fp0YYQc+dDzSJ4b3PLmfbnFTSdI+hNLdtMBvbSBactvqydlmpIm8UbH/PDyAG+dOA==
X-Received: by 2002:a1c:c287:: with SMTP id s129mr1598307wmf.79.1607858096559; 
 Sun, 13 Dec 2020 03:14:56 -0800 (PST)
Received: from krug ([89.180.146.231])
 by smtp.gmail.com with ESMTPSA id h15sm24521929wru.4.2020.12.13.03.14.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 13 Dec 2020 03:14:55 -0800 (PST)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <jwvpn3ehpjz.fsf@HIDDEN> <83mtyierfs.fsf@HIDDEN>
 <jwv360aohw6.fsf-monnier+emacs@HIDDEN> <83ft4ae63m.fsf@HIDDEN>
 <jwvlfe2mj6c.fsf-monnier+emacs@HIDDEN>
Date: Sun, 13 Dec 2020 11:14:53 +0000
In-Reply-To: <jwvlfe2mj6c.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Sat, 12 Dec 2020 23:25:27 -0500")
Message-ID: <87zh2iyn2q.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45198
Cc: bzg@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 45198 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Stefan Monnier <monnier@HIDDEN> writes:

>>> > You cannot usefully call error from redisplay.
>>> Hmm... but this is at the entrance to redisplay, so I though it should
>>> still be safe at that point.  If it's a problem we can replace the above
>>> with
>>>     if (emacs_is_sandboxed)
>>>       return;
>> Yes, I think this is what we should do in this case.
>
> With the change I just installed into `master`, I can now get
> `elisp-flymake-byte-compile` to use sandboxing successfully with the
> revised patch below.

Fantastic!

> Besides the above change, I made the same change in `Fdo_auto_save`
> (i.e. `do-auto-save` was made to just silently do nothing instead of
> signaling an error since it seemed to be too much trouble to change its
> callers to avoid calling it when sandboxed).
>
> I'm still worried that there remain wide open security holes, tho.

First, I wouldn't worry that terribly.  This is certainly and
improvement.  I won't be bitten again like that time I accidentally
typed (delete-directory ".") at macroexpand time.

That said, as you said the whitelisting approach is the safest one.
It'd be nice if you we a way to identify system calls and block all by
default.  Then whitelist a bunch of calls (checking arguments).  Not
sure if this can be done portably/systematically, though.  Chroot also
comes to mind, but it's only for linux, right?

Jo=C3=A3o





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 04:25:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 12 23:25:39 2020
Received: from localhost ([127.0.0.1]:47255 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koIx1-0001ld-1w
	for submit <at> debbugs.gnu.org; Sat, 12 Dec 2020 23:25:39 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21198)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1koIwz-0001lQ-GP
 for 45198 <at> debbugs.gnu.org; Sat, 12 Dec 2020 23:25:38 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E7846440F88;
 Sat, 12 Dec 2020 23:25:31 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 68889440F93;
 Sat, 12 Dec 2020 23:25:29 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1607833529;
 bh=TmfW7nqEXzYwEhYLpo0mvNCF/UldCIaea6/c+w0ADAc=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=IZpFeYPCG8z9fvdGpziXv+hsGqHeCFUKSifFz1EQg0MaJ3gGymW5mgYCAk+gEKT0l
 2aGrdD/JkQbJcuXj/+G2aGf6HkRV/u1/zTNISZZYUOmugif/WmKRu8hqimTxlqapR/
 xM1XR74Hc00mHBNuBB8U4tTNZR7pE0YTKJ/MZctO0X7NkV3znNr6rIyxKGMizkIELf
 AjV3rk2aDQq4qPn49xJ4Z0B5VrPLLTNrKqfXgaCKiJz1Y+2Tr5EF/cfnuV4tDXuM1I
 loCGsttFHD7xQKdnxtcNoCDeugGUoeQBKiGNF06f5FB+S7ADAl3WOmrjf258enss11
 U3XHKnuqbq7iw==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 28618120201;
 Sat, 12 Dec 2020 23:25:29 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwvlfe2mj6c.fsf-monnier+emacs@HIDDEN>
References: <jwvpn3ehpjz.fsf@HIDDEN> <83mtyierfs.fsf@HIDDEN>
 <jwv360aohw6.fsf-monnier+emacs@HIDDEN> <83ft4ae63m.fsf@HIDDEN>
Date: Sat, 12 Dec 2020 23:25:27 -0500
In-Reply-To: <83ft4ae63m.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 13 Dec
 2020 05:29:33 +0200")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.068 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: bzg@HIDDEN, 45198 <at> debbugs.gnu.org, joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> > You cannot usefully call error from redisplay.
>> Hmm... but this is at the entrance to redisplay, so I though it should
>> still be safe at that point.  If it's a problem we can replace the above
>> with
>>     if (emacs_is_sandboxed)
>>       return;
> Yes, I think this is what we should do in this case.

With the change I just installed into `master`, I can now get
`elisp-flymake-byte-compile` to use sandboxing successfully with the
revised patch below.

Besides the above change, I made the same change in `Fdo_auto_save`
(i.e. `do-auto-save` was made to just silently do nothing instead of
signaling an error since it seemed to be too much trouble to change its
callers to avoid calling it when sandboxed).

I'm still worried that there remain wide open security holes, tho.


        Stefan


diff --git a/etc/NEWS b/etc/NEWS
index 909473f4e7..ee51495ca0 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -85,6 +85,16 @@ useful on systems such as FreeBSD which ships only with "etc/termcap".
 
 * Changes in Emacs 28.1
 
+** Sandbox mode to run untrusted code.
+The new function 'sandbox-enter' puts Emacs mode into a state in which
+it can (hopefully) run untrusted code safely.  This mode is restricted such
+that Emacs cannot exit the mode, nor can it write to files or launch
+new processes.  It can still read arbitrary files and communicate over
+pre-existing communication links.  This can only be used in batch mode.
+The expected use is to launch a new batch Emacs session, put it
+into sandbox mode, then run the untrusted code, send back the
+result via 'message', and then exit.
+
 ** Minibuffer scrolling is now conservative by default.
 This is controlled by the new variable 'scroll-minibuffer-conservatively'.
 
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index b7e0c45228..df839d20b9 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -1836,6 +1836,7 @@ elisp-flymake--batch-compile-for-flymake
             (push (list string position fill level)
                   collected)
             t)))
+    (sandbox-enter)
     (unwind-protect
         (byte-compile-file file)
       (ignore-errors
diff --git a/src/emacs-module.c b/src/emacs-module.c
index b7cd835c83..79ff2b6ce6 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -1091,6 +1091,7 @@ DEFUN ("module-load", Fmodule_load, Smodule_load, 1, 1, 0,
        doc: /* Load module FILE.  */)
   (Lisp_Object file)
 {
+  ensure_no_sandbox ();
   dynlib_handle_ptr handle;
   emacs_init_function module_init;
   void *gpl_sym;
@@ -1151,6 +1152,7 @@ DEFUN ("module-load", Fmodule_load, Smodule_load, 1, 1, 0,
 Lisp_Object
 funcall_module (Lisp_Object function, ptrdiff_t nargs, Lisp_Object *arglist)
 {
+  ensure_no_sandbox ();
   const struct Lisp_Module_Function *func = XMODULE_FUNCTION (function);
   eassume (0 <= func->min_arity);
   if (! (func->min_arity <= nargs
diff --git a/src/emacs.c b/src/emacs.c
index 2a32083ba1..0df70ae43e 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -139,6 +139,8 @@ #define MAIN_PROGRAM
 struct gflags gflags;
 bool initialized;
 
+bool emacs_is_sandboxed;
+
 /* If true, Emacs should not attempt to use a window-specific code,
    but instead should use the virtual terminal under which it was started.  */
 bool inhibit_window_system;
@@ -2886,6 +2888,30 @@ DEFUN ("daemon-initialized", Fdaemon_initialized, Sdaemon_initialized, 0, 0, 0,
   return Qt;
 }
 
+DEFUN ("sandbox-enter", Fsandbox_enter, Ssandbox_enter, 0, 0, 0,
+  doc: /* Put Emacs in sandboxed mode.
+After calling this function, Emacs cannot have externally visible
+side effects any more.  For example, it will not be able to write to files,
+create new processes, open new displays, or call functionality provided by
+modules, ...
+It can still send data to pre-existing processes, on the other hand.
+There is no mechanism to exit sandboxed mode.  */)
+  (void)
+{
+  if (!noninteractive)
+    /* We could allow a sandbox in interactive sessions, but it seems
+       useless, so we'll assume that it was a pilot-error.  */
+    error ("Can't enter sandbox in interactive session");
+  emacs_is_sandboxed = true;
+  return Qnil;
+}
+
+void ensure_no_sandbox (void)
+{
+  if (emacs_is_sandboxed)
+    error ("Sandboxed");
+}
+
 void
 syms_of_emacs (void)
 {
@@ -2906,6 +2932,7 @@ syms_of_emacs (void)
   defsubr (&Sinvocation_directory);
   defsubr (&Sdaemonp);
   defsubr (&Sdaemon_initialized);
+  defsubr (&Ssandbox_enter);
 
   DEFVAR_LISP ("command-line-args", Vcommand_line_args,
 	       doc: /* Args passed by shell to Emacs, as a list of strings.
diff --git a/src/fileio.c b/src/fileio.c
index 702c143828..509341351d 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -689,6 +689,7 @@ DEFUN ("make-temp-file-internal", Fmake_temp_file_internal,
   (Lisp_Object prefix, Lisp_Object dir_flag, Lisp_Object suffix,
    Lisp_Object text)
 {
+  ensure_no_sandbox ();
   CHECK_STRING (prefix);
   CHECK_STRING (suffix);
   Lisp_Object encoded_prefix = ENCODE_FILE (prefix);
@@ -2043,6 +2044,7 @@ DEFUN ("copy-file", Fcopy_file, Scopy_file, 2, 6,
    Lisp_Object keep_time, Lisp_Object preserve_uid_gid,
    Lisp_Object preserve_permissions)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object encoded_file, encoded_newname;
@@ -2301,6 +2303,7 @@ DEFUN ("make-directory-internal", Fmake_directory_internal,
        doc: /* Create a new directory named DIRECTORY.  */)
   (Lisp_Object directory)
 {
+  ensure_no_sandbox ();
   const char *dir;
   Lisp_Object handler;
   Lisp_Object encoded_dir;
@@ -2327,6 +2330,7 @@ DEFUN ("delete-directory-internal", Fdelete_directory_internal,
        doc: /* Delete the directory named DIRECTORY.  Does not follow symlinks.  */)
   (Lisp_Object directory)
 {
+  ensure_no_sandbox ();
   const char *dir;
   Lisp_Object encoded_dir;
 
@@ -2356,6 +2360,7 @@ DEFUN ("delete-file", Fdelete_file, Sdelete_file, 1, 2,
 With a prefix argument, TRASH is nil.  */)
   (Lisp_Object filename, Lisp_Object trash)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   Lisp_Object encoded_file;
 
@@ -2494,6 +2499,7 @@ DEFUN ("rename-file", Frename_file, Srename_file, 2, 3,
 This is what happens in interactive use with M-x.  */)
   (Lisp_Object file, Lisp_Object newname, Lisp_Object ok_if_already_exists)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   Lisp_Object encoded_file, encoded_newname;
 
@@ -2614,6 +2620,7 @@ DEFUN ("add-name-to-file", Fadd_name_to_file, Sadd_name_to_file, 2, 3,
 This is what happens in interactive use with M-x.  */)
   (Lisp_Object file, Lisp_Object newname, Lisp_Object ok_if_already_exists)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   Lisp_Object encoded_file, encoded_newname;
 
@@ -2667,6 +2674,7 @@ DEFUN ("make-symbolic-link", Fmake_symbolic_link, Smake_symbolic_link, 2, 3,
 This happens for interactive use with M-x.  */)
   (Lisp_Object target, Lisp_Object linkname, Lisp_Object ok_if_already_exists)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   Lisp_Object encoded_target, encoded_linkname;
 
@@ -3176,6 +3184,7 @@ DEFUN ("set-file-selinux-context", Fset_file_selinux_context,
 or if Emacs was not compiled with SELinux support.  */)
   (Lisp_Object filename, Lisp_Object context)
 {
+  ensure_no_sandbox ();
   Lisp_Object absname;
   Lisp_Object handler;
 #if HAVE_LIBSELINUX
@@ -3307,6 +3316,7 @@ DEFUN ("set-file-acl", Fset_file_acl, Sset_file_acl,
 support.  */)
   (Lisp_Object filename, Lisp_Object acl_string)
 {
+  ensure_no_sandbox ();
 #if USE_ACL
   Lisp_Object absname;
   Lisp_Object handler;
@@ -3392,6 +3402,7 @@ DEFUN ("set-file-modes", Fset_file_modes, Sset_file_modes, 2, 3,
 symbolic notation, like the `chmod' command from GNU Coreutils.  */)
   (Lisp_Object filename, Lisp_Object mode, Lisp_Object flag)
 {
+  ensure_no_sandbox ();
   CHECK_FIXNUM (mode);
   int nofollow = symlink_nofollow_flag (flag);
   Lisp_Object absname = Fexpand_file_name (filename,
@@ -3458,6 +3469,7 @@ DEFUN ("set-file-times", Fset_file_times, Sset_file_times, 1, 3, 0,
 TIMESTAMP is in the format of `current-time'. */)
   (Lisp_Object filename, Lisp_Object timestamp, Lisp_Object flag)
 {
+  ensure_no_sandbox ();
   int nofollow = symlink_nofollow_flag (flag);
 
   struct timespec ts[2];
@@ -5039,6 +5051,7 @@ DEFUN ("write-region", Fwrite_region, Swrite_region, 3, 7,
   (Lisp_Object start, Lisp_Object end, Lisp_Object filename, Lisp_Object append,
    Lisp_Object visit, Lisp_Object lockname, Lisp_Object mustbenew)
 {
+  ensure_no_sandbox ();
   return write_region (start, end, filename, append, visit, lockname, mustbenew,
 		       -1);
 }
@@ -5837,6 +5850,8 @@ DEFUN ("do-auto-save", Fdo_auto_save, Sdo_auto_save, 0, 2, "",
 A non-nil CURRENT-ONLY argument means save only current buffer.  */)
   (Lisp_Object no_message, Lisp_Object current_only)
 {
+  if (emacs_is_sandboxed)
+    return Qnil;
   struct buffer *old = current_buffer, *b;
   Lisp_Object tail, buf, hook;
   bool auto_saved = 0;
diff --git a/src/lisp.h b/src/lisp.h
index e83304462f..107a2d9f03 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -603,6 +603,10 @@ #define ENUM_BF(TYPE) enum TYPE
    subsequent starts.  */
 extern bool initialized;
 
+/* Whether we've been neutralized.  */
+extern bool emacs_is_sandboxed;
+extern void ensure_no_sandbox (void);
+
 extern struct gflags
 {
   /* True means this Emacs instance was born to dump.  */
diff --git a/src/process.c b/src/process.c
index 4fe8ac7fc0..68460868c4 100644
--- a/src/process.c
+++ b/src/process.c
@@ -862,6 +862,8 @@ allocate_pty (char pty_name[PTY_NAME_SIZE])
 static struct Lisp_Process *
 allocate_process (void)
 {
+  ensure_no_sandbox ();
+
   return ALLOCATE_ZEROED_PSEUDOVECTOR (struct Lisp_Process, thread,
 				       PVEC_PROCESS);
 }
diff --git a/src/xdisp.c b/src/xdisp.c
index 96dd4fade2..04972c248e 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -15442,6 +15442,11 @@ #define RESUME_POLLING					\
 static void
 redisplay_internal (void)
 {
+  /* Not sure if it's important to avoid redisplay inside a sandbox,
+     but it seems safer to avoid risking introducing security holes via
+     image libraries and such.  */
+  if (emacs_is_sandboxed)
+    return;
   struct window *w = XWINDOW (selected_window);
   struct window *sw;
   struct frame *fr;
diff --git a/src/xterm.c b/src/xterm.c
index 3de0d2e73c..e8a4d2f29d 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -12698,6 +12698,7 @@ x_term_init (Lisp_Object display_name, char *xrm_option, char *resource_name)
   xcb_connection_t *xcb_conn;
 #endif
 
+  ensure_no_sandbox ();
   block_input ();
 
   if (!x_initialized)





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 13 Dec 2020 03:29:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 12 22:29:55 2020
Received: from localhost ([127.0.0.1]:47229 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koI55-0000GL-5J
	for submit <at> debbugs.gnu.org; Sat, 12 Dec 2020 22:29:55 -0500
Received: from eggs.gnu.org ([209.51.188.92]:40324)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1koI52-0000G8-LC
 for 45198 <at> debbugs.gnu.org; Sat, 12 Dec 2020 22:29:53 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:57314)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1koI4w-00021j-TF; Sat, 12 Dec 2020 22:29:46 -0500
Received: from [176.228.60.248] (port=4104 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1koI4v-0004oZ-5Y; Sat, 12 Dec 2020 22:29:45 -0500
Date: Sun, 13 Dec 2020 05:29:33 +0200
Message-Id: <83ft4ae63m.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwv360aohw6.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 12 Dec 2020 16:06:54 -0500)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <jwvpn3ehpjz.fsf@HIDDEN> <83mtyierfs.fsf@HIDDEN>
 <jwv360aohw6.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: bzg@HIDDEN, 45198 <at> debbugs.gnu.org, joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 45198 <at> debbugs.gnu.org,  bzg@HIDDEN,  joaotavora@HIDDEN
> Date: Sat, 12 Dec 2020 16:06:54 -0500
> 
> > You cannot usefully call error from redisplay.
> 
> Hmm... but this is at the entrance to redisplay, so I though it should
> still be safe at that point.  If it's a problem we can replace the above
> with
> 
>     if (emacs_is_sandboxed)
>       return;

Yes, I think this is what we should do in this case.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 12 Dec 2020 21:07:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 12 16:07:05 2020
Received: from localhost ([127.0.0.1]:46904 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koC6a-0004rD-NE
	for submit <at> debbugs.gnu.org; Sat, 12 Dec 2020 16:07:04 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28953)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1koC6Y-0004qd-FJ
 for 45198 <at> debbugs.gnu.org; Sat, 12 Dec 2020 16:07:03 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D542D440F7E;
 Sat, 12 Dec 2020 16:06:56 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A9FE2440859;
 Sat, 12 Dec 2020 16:06:55 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1607807215;
 bh=Twac/IHdDuKLecpgyh+5kVryS3lVw+lulK0AT9VCukw=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=ZVvpHT3qU906gSGAhekueYWWj+gjUZYop9eBnYOPU4YdByuoskKeK4/2Q6++2IpLW
 811Q6Zaj8a0XAo78LGLptI84ACEKwko0W8G7tTZ8Agoj7c3kxkZq9aP1ohKa87Wiox
 ZueYwhWZU/WbqGEsMU7AwEQmUhmHN+V0sBN2KvHtH34Y5enfvNLx38tXQbTPZ7YUzk
 YzvzSu4FHWtVlGlKAOk4eavJoc+g+CJLzRIW+OvTSSlxPS8DS+rT5/bvMl8RuvPS00
 +yoRkUa/BI8ARThfkIGMlauSwemjRlgSZVwn23Izx6OHbhXpQ3m9gDscvB1RiP0Ti4
 QRrffduVOrA3w==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3058612061D;
 Sat, 12 Dec 2020 16:06:55 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwv360aohw6.fsf-monnier+emacs@HIDDEN>
References: <jwvpn3ehpjz.fsf@HIDDEN> <83mtyierfs.fsf@HIDDEN>
Date: Sat, 12 Dec 2020 16:06:54 -0500
In-Reply-To: <83mtyierfs.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 12 Dec
 2020 21:48:39 +0200")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.069 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: bzg@HIDDEN, 45198 <at> debbugs.gnu.org, joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>  static void
>>  redisplay_internal (void)
>>  {
>> +  /* Not sure if it's important to avoid redisplay inside a sandbox,
>> +     but it seems safer to avoid risking introducing security holes via
>> +     image libraries and such.  */
>> +  ensure_no_sandbox ();
>
> You cannot usefully call error from redisplay.

Hmm... but this is at the entrance to redisplay, so I though it should
still be safe at that point.  If it's a problem we can replace the above
with

    if (emacs_is_sandboxed)
      return;


-- Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at 45198 <at> debbugs.gnu.org:


Received: (at 45198) by debbugs.gnu.org; 12 Dec 2020 19:49:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 12 14:49:02 2020
Received: from localhost ([127.0.0.1]:46664 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koAt3-0006qQ-R7
	for submit <at> debbugs.gnu.org; Sat, 12 Dec 2020 14:49:02 -0500
Received: from eggs.gnu.org ([209.51.188.92]:47476)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1koAt2-0006py-2z
 for 45198 <at> debbugs.gnu.org; Sat, 12 Dec 2020 14:49:00 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:50666)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1koAsw-00014q-MR; Sat, 12 Dec 2020 14:48:54 -0500
Received: from [176.228.60.248] (port=3847 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1koAsu-0000Se-RI; Sat, 12 Dec 2020 14:48:53 -0500
Date: Sat, 12 Dec 2020 21:48:39 +0200
Message-Id: <83mtyierfs.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvpn3ehpjz.fsf@HIDDEN> (message from Stefan Monnier
 on Sat, 12 Dec 2020 13:01:04 -0500)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <jwvpn3ehpjz.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: bzg@HIDDEN, 45198 <at> debbugs.gnu.org, joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Date: Sat, 12 Dec 2020 13:01:04 -0500
> Cc: Bastien <bzg@HIDDEN>,
>  Joo Tvora <joaotavora@HIDDEN>
> 
>  static void
>  redisplay_internal (void)
>  {
> +  /* Not sure if it's important to avoid redisplay inside a sandbox,
> +     but it seems safer to avoid risking introducing security holes via
> +     image libraries and such.  */
> +  ensure_no_sandbox ();

You cannot usefully call error from redisplay.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 12 Dec 2020 18:19:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 12 13:19:48 2020
Received: from localhost ([127.0.0.1]:46384 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ko9Uh-00005r-G9
	for submit <at> debbugs.gnu.org; Sat, 12 Dec 2020 13:19:48 -0500
Received: from lists.gnu.org ([209.51.188.17]:59840)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1ko9Uf-00005i-O7
 for submit <at> debbugs.gnu.org; Sat, 12 Dec 2020 13:19:46 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:57788)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <monnier@HIDDEN>)
 id 1ko9Uf-0001Ug-HC
 for bug-gnu-emacs@HIDDEN; Sat, 12 Dec 2020 13:19:45 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40496)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <monnier@HIDDEN>)
 id 1ko9UZ-0002Je-4U
 for bug-gnu-emacs@HIDDEN; Sat, 12 Dec 2020 13:19:44 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 70572440F18
 for <bug-gnu-emacs@HIDDEN>; Sat, 12 Dec 2020 13:01:10 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8766E440C81
 for <bug-gnu-emacs@HIDDEN>; Sat, 12 Dec 2020 13:01:05 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1607796065;
 bh=6moWS3PcQQwNhJrOlK2HH1Zp99YpES4JTXd/Kwohx2M=;
 h=From:To:Subject:Date:From;
 b=QEFcd6Y/qxeokKcIkoKiL1cbk59eotbql6FsDizKrV3zOvbzlPq9ab+pfjBpEVDQB
 KbD41x+AeVXxmAoJKL/rR3nmD3KGvqLnimeyhZY5axBWrEesyIGf9RM/5GWub347hp
 08TONzyu1+M3vSdDBOnV/OAsDtnw1kosNYare4J9Y6dQFyccFi6UAcmV/gecAiZ/vx
 DlwT3jP50X5788NkCnmCt3GDGiiVYwSabVBp4eOWzM55gpXIEj6vA2sZB+kKuAcMkN
 0tKYvXj3ZLZ6kLev64Z4/NVJCQ9mSg999DwGP17U4ePlMzld5hdXGJrk5tcImRr/K1
 B5RF0wYu86EmQ==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 59FD712045F
 for <bug-gnu-emacs@HIDDEN>; Sat, 12 Dec 2020 13:01:05 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 28.0.50; Sandbox mode
X-debbugs-Cc: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN>,
 Bastien <bzg@HIDDEN>
Date: Sat, 12 Dec 2020 13:01:04 -0500
Message-ID: <jwvpn3ehpjz.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.068 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
Received-SPF: pass client-ip=132.204.25.50;
 envelope-from=monnier@HIDDEN; helo=mailscanner.iro.umontreal.ca
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Package: Emacs
Version: 28.0.50


Currently we cannot enable `flymake-mode` by default in `elisp-mode`
for simple reasons of security: having this mode enabled means that
whenever we happen to open a file containing ELisp code, our
Emacs will happily try to compile this file, including evaluating
arbitrary code contained in its macros.

Similarly, elpa.gnu.org can't automatically take a documentation file in
Org format and convert it to Texinfo (and then Info) when generating
a package's tarball, because the Org -> Texinfo conversion can run
arbitrary code.

To try and address these problems I suggest the function `sandbox-enter`
in the patch below, which should let us run untrusted ELisp code safely
(in an Emacs subprocess).

The patch for `elisp-flymake-byte-compile` is just there to give an idea
of how I expect it to work: currently the compiler will still try to write
the result of its compilation, which will fail because we're now
sandboxed, so it needs more work before it behaves like it should.

One thing I'm particularly eager to hear your opinion about is whether
there might be more holes to plug (i.e. more places where we need to
call `ensure_no_sandbox`).  Clearly, from a security perspective, this is
the main drawback of this approach: it's based on a black list rather
than on a whitelist.  Still, I have the impression that it should
be manageable.


        Stefan


diff --git a/etc/NEWS b/etc/NEWS
index 514209516d..9a569b4bd2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -85,6 +85,16 @@ useful on systems such as FreeBSD which ships only with "etc/termcap".
 
 * Changes in Emacs 28.1
 
+** Sandbox mode to run untrusted code.
+The new function 'sandbox-enter' puts Emacs mode into a state in which
+it can (hopefully) run untrusted code safely.  This mode is restricted such
+that Emacs cannot exit the mode, nor can it write to files or launch
+new processes.  It can still read arbitrary files and communicate over
+pre-existing communication links.  This can only be used in batch mode.
+The expected use is to launch a new batch Emacs session, put it
+into sandbox mode, then run the untrusted code, send back the
+result via 'message', and then exit.
+
 ** Minibuffer scrolling is now conservative by default.
 This is controlled by the new variable 'scroll-minibuffer-conservatively'.
 
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index fa360a8f3f..189ee896b6 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -1839,6 +1839,7 @@ elisp-flymake--batch-compile-for-flymake
             (push (list string position fill level)
                   collected)
             t)))
+    (sandbox-enter)     ;FIXME: this will break the subsequent delete-file!
     (unwind-protect
         (byte-compile-file file)
       (ignore-errors
diff --git a/src/emacs-module.c b/src/emacs-module.c
index 0f3ef59fd8..1bebdfeb4a 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -1091,6 +1091,7 @@ DEFUN ("module-load", Fmodule_load, Smodule_load, 1, 1, 0,
        doc: /* Load module FILE.  */)
   (Lisp_Object file)
 {
+  ensure_no_sandbox ();
   dynlib_handle_ptr handle;
   emacs_init_function module_init;
   void *gpl_sym;
@@ -1151,6 +1152,7 @@ DEFUN ("module-load", Fmodule_load, Smodule_load, 1, 1, 0,
 Lisp_Object
 funcall_module (Lisp_Object function, ptrdiff_t nargs, Lisp_Object *arglist)
 {
+  ensure_no_sandbox ();
   const struct Lisp_Module_Function *func = XMODULE_FUNCTION (function);
   eassume (0 <= func->min_arity);
   if (! (func->min_arity <= nargs
diff --git a/src/emacs.c b/src/emacs.c
index 2a32083ba1..0df70ae43e 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -139,6 +139,8 @@ #define MAIN_PROGRAM
 struct gflags gflags;
 bool initialized;
 
+bool emacs_is_sandboxed;
+
 /* If true, Emacs should not attempt to use a window-specific code,
    but instead should use the virtual terminal under which it was started.  */
 bool inhibit_window_system;
@@ -2886,6 +2888,30 @@ DEFUN ("daemon-initialized", Fdaemon_initialized, Sdaemon_initialized, 0, 0, 0,
   return Qt;
 }
 
+DEFUN ("sandbox-enter", Fsandbox_enter, Ssandbox_enter, 0, 0, 0,
+  doc: /* Put Emacs in sandboxed mode.
+After calling this function, Emacs cannot have externally visible
+side effects any more.  For example, it will not be able to write to files,
+create new processes, open new displays, or call functionality provided by
+modules, ...
+It can still send data to pre-existing processes, on the other hand.
+There is no mechanism to exit sandboxed mode.  */)
+  (void)
+{
+  if (!noninteractive)
+    /* We could allow a sandbox in interactive sessions, but it seems
+       useless, so we'll assume that it was a pilot-error.  */
+    error ("Can't enter sandbox in interactive session");
+  emacs_is_sandboxed = true;
+  return Qnil;
+}
+
+void ensure_no_sandbox (void)
+{
+  if (emacs_is_sandboxed)
+    error ("Sandboxed");
+}
+
 void
 syms_of_emacs (void)
 {
@@ -2906,6 +2932,7 @@ syms_of_emacs (void)
   defsubr (&Sinvocation_directory);
   defsubr (&Sdaemonp);
   defsubr (&Sdaemon_initialized);
+  defsubr (&Ssandbox_enter);
 
   DEFVAR_LISP ("command-line-args", Vcommand_line_args,
 	       doc: /* Args passed by shell to Emacs, as a list of strings.
diff --git a/src/fileio.c b/src/fileio.c
index 702c143828..e221048493 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -689,6 +689,7 @@ DEFUN ("make-temp-file-internal", Fmake_temp_file_internal,
   (Lisp_Object prefix, Lisp_Object dir_flag, Lisp_Object suffix,
    Lisp_Object text)
 {
+  ensure_no_sandbox ();
   CHECK_STRING (prefix);
   CHECK_STRING (suffix);
   Lisp_Object encoded_prefix = ENCODE_FILE (prefix);
@@ -2043,6 +2044,7 @@ DEFUN ("copy-file", Fcopy_file, Scopy_file, 2, 6,
    Lisp_Object keep_time, Lisp_Object preserve_uid_gid,
    Lisp_Object preserve_permissions)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   ptrdiff_t count = SPECPDL_INDEX ();
   Lisp_Object encoded_file, encoded_newname;
@@ -2301,6 +2303,7 @@ DEFUN ("make-directory-internal", Fmake_directory_internal,
        doc: /* Create a new directory named DIRECTORY.  */)
   (Lisp_Object directory)
 {
+  ensure_no_sandbox ();
   const char *dir;
   Lisp_Object handler;
   Lisp_Object encoded_dir;
@@ -2327,6 +2330,7 @@ DEFUN ("delete-directory-internal", Fdelete_directory_internal,
        doc: /* Delete the directory named DIRECTORY.  Does not follow symlinks.  */)
   (Lisp_Object directory)
 {
+  ensure_no_sandbox ();
   const char *dir;
   Lisp_Object encoded_dir;
 
@@ -2356,6 +2360,7 @@ DEFUN ("delete-file", Fdelete_file, Sdelete_file, 1, 2,
 With a prefix argument, TRASH is nil.  */)
   (Lisp_Object filename, Lisp_Object trash)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   Lisp_Object encoded_file;
 
@@ -2494,6 +2499,7 @@ DEFUN ("rename-file", Frename_file, Srename_file, 2, 3,
 This is what happens in interactive use with M-x.  */)
   (Lisp_Object file, Lisp_Object newname, Lisp_Object ok_if_already_exists)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   Lisp_Object encoded_file, encoded_newname;
 
@@ -2614,6 +2620,7 @@ DEFUN ("add-name-to-file", Fadd_name_to_file, Sadd_name_to_file, 2, 3,
 This is what happens in interactive use with M-x.  */)
   (Lisp_Object file, Lisp_Object newname, Lisp_Object ok_if_already_exists)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   Lisp_Object encoded_file, encoded_newname;
 
@@ -2667,6 +2674,7 @@ DEFUN ("make-symbolic-link", Fmake_symbolic_link, Smake_symbolic_link, 2, 3,
 This happens for interactive use with M-x.  */)
   (Lisp_Object target, Lisp_Object linkname, Lisp_Object ok_if_already_exists)
 {
+  ensure_no_sandbox ();
   Lisp_Object handler;
   Lisp_Object encoded_target, encoded_linkname;
 
@@ -3176,6 +3184,7 @@ DEFUN ("set-file-selinux-context", Fset_file_selinux_context,
 or if Emacs was not compiled with SELinux support.  */)
   (Lisp_Object filename, Lisp_Object context)
 {
+  ensure_no_sandbox ();
   Lisp_Object absname;
   Lisp_Object handler;
 #if HAVE_LIBSELINUX
@@ -3307,6 +3316,7 @@ DEFUN ("set-file-acl", Fset_file_acl, Sset_file_acl,
 support.  */)
   (Lisp_Object filename, Lisp_Object acl_string)
 {
+  ensure_no_sandbox ();
 #if USE_ACL
   Lisp_Object absname;
   Lisp_Object handler;
@@ -3392,6 +3402,7 @@ DEFUN ("set-file-modes", Fset_file_modes, Sset_file_modes, 2, 3,
 symbolic notation, like the `chmod' command from GNU Coreutils.  */)
   (Lisp_Object filename, Lisp_Object mode, Lisp_Object flag)
 {
+  ensure_no_sandbox ();
   CHECK_FIXNUM (mode);
   int nofollow = symlink_nofollow_flag (flag);
   Lisp_Object absname = Fexpand_file_name (filename,
@@ -3458,6 +3469,7 @@ DEFUN ("set-file-times", Fset_file_times, Sset_file_times, 1, 3, 0,
 TIMESTAMP is in the format of `current-time'. */)
   (Lisp_Object filename, Lisp_Object timestamp, Lisp_Object flag)
 {
+  ensure_no_sandbox ();
   int nofollow = symlink_nofollow_flag (flag);
 
   struct timespec ts[2];
@@ -5039,6 +5051,7 @@ DEFUN ("write-region", Fwrite_region, Swrite_region, 3, 7,
   (Lisp_Object start, Lisp_Object end, Lisp_Object filename, Lisp_Object append,
    Lisp_Object visit, Lisp_Object lockname, Lisp_Object mustbenew)
 {
+  ensure_no_sandbox ();
   return write_region (start, end, filename, append, visit, lockname, mustbenew,
 		       -1);
 }
@@ -5837,6 +5850,7 @@ DEFUN ("do-auto-save", Fdo_auto_save, Sdo_auto_save, 0, 2, "",
 A non-nil CURRENT-ONLY argument means save only current buffer.  */)
   (Lisp_Object no_message, Lisp_Object current_only)
 {
+  ensure_no_sandbox ();
   struct buffer *old = current_buffer, *b;
   Lisp_Object tail, buf, hook;
   bool auto_saved = 0;
diff --git a/src/lisp.h b/src/lisp.h
index e83304462f..107a2d9f03 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -603,6 +603,10 @@ #define ENUM_BF(TYPE) enum TYPE
    subsequent starts.  */
 extern bool initialized;
 
+/* Whether we've been neutralized.  */
+extern bool emacs_is_sandboxed;
+extern void ensure_no_sandbox (void);
+
 extern struct gflags
 {
   /* True means this Emacs instance was born to dump.  */
diff --git a/src/process.c b/src/process.c
index 4fe8ac7fc0..68460868c4 100644
--- a/src/process.c
+++ b/src/process.c
@@ -862,6 +862,8 @@ allocate_pty (char pty_name[PTY_NAME_SIZE])
 static struct Lisp_Process *
 allocate_process (void)
 {
+  ensure_no_sandbox ();
+
   return ALLOCATE_ZEROED_PSEUDOVECTOR (struct Lisp_Process, thread,
 				       PVEC_PROCESS);
 }
diff --git a/src/xdisp.c b/src/xdisp.c
index 96dd4fade2..72c37e8194 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -15442,6 +15442,10 @@ #define RESUME_POLLING					\
 static void
 redisplay_internal (void)
 {
+  /* Not sure if it's important to avoid redisplay inside a sandbox,
+     but it seems safer to avoid risking introducing security holes via
+     image libraries and such.  */
+  ensure_no_sandbox ();
   struct window *w = XWINDOW (selected_window);
   struct window *sw;
   struct frame *fr;
diff --git a/src/xterm.c b/src/xterm.c
index 3de0d2e73c..e8a4d2f29d 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -12698,6 +12698,7 @@ x_term_init (Lisp_Object display_name, char *xrm_option, char *resource_name)
   xcb_connection_t *xcb_conn;
 #endif
 
+  ensure_no_sandbox ();
   block_input ();
 
   if (!x_initialized)





Acknowledgement sent to Stefan Monnier <monnier@HIDDEN>:
New bug report received and forwarded. Copy sent to joaotavora@HIDDEN, bzg@HIDDEN, bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to joaotavora@HIDDEN, bzg@HIDDEN, bug-gnu-emacs@HIDDEN:
bug#45198; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 20 Dec 2020 18:15:02 UTC

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