GNU bug report logs - #45198
28.0.50; Sandbox mode

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

Received: (at 45198) by debbugs.gnu.org; 13 Sep 2022 12:37:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 13 08:37:15 2022
Received: from localhost ([127.0.0.1]:49213 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oY5AB-0000Ll-9u
	for submit <at> debbugs.gnu.org; Tue, 13 Sep 2022 08:37:15 -0400
Received: from mail234c50.megamailservers.eu ([91.136.10.244]:54154
 helo=mail37c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1oY5A8-0000LW-HX
 for 45198 <at> debbugs.gnu.org; Tue, 13 Sep 2022 08:37:14 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1663072630;
 bh=OEYKuutqjSJAJTyzMdziMCIhmOcNTPax8LZbAubfGRA=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=IftN/mYbEqJzRDi8I0CRchBdwZjX4Rwhys4zMZ4D8vtyiw52KVF/VQEEP/PFzPrPS
 mUAFKRlHRIOdNPttxcXpm65ijqiHRVKJ1fY6JsxLs54FodfVSBOypwkDZsbS8y4qA/
 mtaEl+446t8I0nUkW1UsELDgX2YhAFmqSFdocAXI=
Feedback-ID: mattiase@HIDDEN
Received: from smtpclient.apple (c188-150.188-179.bredband.tele2.se
 [188.150.188.179] (may be forged)) (authenticated bits=0)
 by mail37c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 28DCb7Yo121912; 
 Tue, 13 Sep 2022 12:37:08 +0000
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: mattiase@HIDDEN
In-Reply-To: <87pmg2f8uz.fsf@HIDDEN>
Date: Tue, 13 Sep 2022 14:37:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E355F21-1D0A-45AC-B33F-7C9FD1027F26@HIDDEN>
References: <DCB89188-A9D5-4A64-8DD2-BE1DD8A2B202@HIDDEN>
 <jwvfsu3732l.fsf-monnier+emacs@HIDDEN>
 <8355EDD1-FF78-43B1-8F96-4EB3316E8FEB@HIDDEN> <87pmg2f8uz.fsf@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-CTCH-RefID: str=0001.0A782F24.63207976.003B, 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-Origin-Country: SE
X-Spam-Score: 2.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: 11 sep. 2022 kl. 13.28 skrev Lars Ingebrigtsen
 <larsi@HIDDEN>:
 > This was a year ago, but it looks like none of these patches were > applied?
 Probably means they weren't very good to begin with. 
 Content analysis details:   (2.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.0 T_SCC_BODY_TEXT_LINE   No description available.
 1.0 MAY_BE_FORGED          Relay IP's reverse DNS does not resolve to IP
 0.4 KHOP_HELO_FCRDNS       Relay HELO differs from its IP's reverse DNS
X-Debbugs-Envelope-To: 45198
Cc: Alan Third <alan@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefan@HIDDEN>, Philipp <p.stephani2@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@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 (/)

11 sep. 2022 kl. 13.28 skrev Lars Ingebrigtsen <larsi@HIDDEN>:

> This was a year ago, but it looks like none of these patches were
> applied?

Probably means they weren't very good to begin with.

> I think having a sandbox mode would certainly be good in principle.

Same here, but I know how perilous it is to design interfaces without a =
concrete and obviously useful application from the start so let's be =
careful.

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

Received: (at 45198) by debbugs.gnu.org; 11 Sep 2022 11:28:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 11 07:28:54 2022
Received: from localhost ([127.0.0.1]:40938 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oXL8w-0003RB-Gy
	for submit <at> debbugs.gnu.org; Sun, 11 Sep 2022 07:28:54 -0400
Received: from quimby.gnus.org ([95.216.78.240]:39462)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1oXL8u-0003Qy-LH
 for 45198 <at> debbugs.gnu.org; Sun, 11 Sep 2022 07:28:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID
 :Date:References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=anjljJpxS4wmrx04pk/rpAVeFRPvX6DfzValEMeKRik=; b=Pcw1/jbWfSpf+7/rd+rhw0IoQ6
 Z44cvGxYoOxDSqIFkMfvLLYga+6H6ShwPZSiMw90nTCEVaSk7wWa0QEHnxAqi7o+NEldbwbFQmpJO
 gJof1dyXyTIqeM3boI6/VkIa/8YPi/YUwRCp9jX9R/LmgcP4dt/FiDgnntgFMFA7e0vI=;
Received: from [84.212.220.105] (helo=joga)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1oXL8e-0003rV-UJ; Sun, 11 Sep 2022 13:28:39 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
In-Reply-To: <8355EDD1-FF78-43B1-8F96-4EB3316E8FEB@HIDDEN> ("Mattias
 =?utf-8?Q?Engdeg=C3=A5rd=22's?= message of "Fri, 17 Sep 2021 21:49:39
 +0200")
References: <DCB89188-A9D5-4A64-8DD2-BE1DD8A2B202@HIDDEN>
 <jwvfsu3732l.fsf-monnier+emacs@HIDDEN>
 <8355EDD1-FF78-43B1-8F96-4EB3316E8FEB@HIDDEN>
X-Now-Playing: Insides's _Euphoria_: "Skykicking"
Date: Sun, 11 Sep 2022 13:28:36 +0200
Message-ID: <87pmg2f8uz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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
 @@CONTACT_ADDRESS@@ for details.
 
 Content preview:  Mattias Engdegård <mattiase@HIDDEN> writes: > Of course
   this whole exercise doesn't really touch the questions that > really matter,
    such as whether it is practical for actual use. This was a year ago, but
   it looks like none of these patches were applied? 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45198
Cc: Alan Third <alan@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefan@HIDDEN>, Philipp <p.stephani2@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 =?utf-8?B?Sm8=?= =?utf-8?B?w6NvIFTDoXZvcmE=?= <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 (---)

Mattias Engdeg=C3=A5rd <mattiase@HIDDEN> writes:

> Of course this whole exercise doesn't really touch the questions that
> really matter, such as whether it is practical for actual use.

This was a year ago, but it looks like none of these patches were
applied?

I think having a sandbox mode would certainly be good in principle.

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

Received: (at 45198) by debbugs.gnu.org; 17 Sep 2021 19:49:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 17 15:49:57 2021
Received: from localhost ([127.0.0.1]:33054 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mRJrx-0003B4-G9
	for submit <at> debbugs.gnu.org; Fri, 17 Sep 2021 15:49:57 -0400
Received: from mail1449c50.megamailservers.eu ([91.136.14.49]:56108
 helo=mail265c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1mRJrs-0003Ak-5I
 for 45198 <at> debbugs.gnu.org; Fri, 17 Sep 2021 15:49:55 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1631908184;
 bh=fEzvJxKTeOE8t5f2hV775ozI3pqxTvzV2aj3dXAlmvk=;
 h=From:Subject:Date:In-Reply-To:Cc:To:References:From;
 b=Tb3PqEzXIZ5bIXPVRfQTEc/2+E72baAXpCHwb3u6gc1agdQH+gWOQCB8zLfGVGZn1
 ghmI8lG+oMyHGPfIQIpgIXBj+5MqIP3LQ5P/ANNFmTUrJLljHn80XyVibyK8m8TUZj
 jj2cdTNhZmdIDodMvmh5Pomn+0UxTksfwSTVfIQE=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] (c188-150-171-71.bredband.tele2.se
 [188.150.171.71]) (authenticated bits=0)
 by mail265c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 18HJnevZ019213; 
 Fri, 17 Sep 2021 19:49:42 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Message-Id: <8355EDD1-FF78-43B1-8F96-4EB3316E8FEB@HIDDEN>
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_E7692CE5-7A32-4E92-BD0A-A145CC42C55F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Date: Fri, 17 Sep 2021 21:49:39 +0200
In-Reply-To: <jwvfsu3732l.fsf-monnier+emacs@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
References: <DCB89188-A9D5-4A64-8DD2-BE1DD8A2B202@HIDDEN>
 <jwvfsu3732l.fsf-monnier+emacs@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.21)
X-CTCH-RefID: str=0001.0A742F22.6144F158.006A, 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.4 cv=adICITkt c=1 sm=1 tr=0 ts=6144f158
 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17
 a=M51BFTxLslgA:10 a=iRZporoAAAAA:8 a=wuWo1mPVt09aIbERY5QA:9
 a=CjuIK1q_8ugA:10 a=2i1jUgeGfihAGWfHL1kA:9 a=B2y7HmGcmWMA:10
 a=7yj0kKAPgQKSsoQ_J6wA:9 a=NOBgFS-JBQ2l-kSd6-zu:22
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: 17 sep. 2021 kl. 15.20 skrev Stefan Monnier
 <monnier@HIDDEN>:
 > For `elpa-admin.el` we need a writable directory as well. > We also need
 the ability to run sub-processes. Your `bwrap` > implementation for GNU/Linux
 should allow that, AFAICT, but I can't tell > i [...] 
 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: Alan Third <alan@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefan@HIDDEN>, Philipp <p.stephani2@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
 Eli Zaretskii <eliz@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 (/)


--Apple-Mail=_E7692CE5-7A32-4E92-BD0A-A145CC42C55F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

17 sep. 2021 kl. 15.20 skrev Stefan Monnier <monnier@HIDDEN>:

> For `elpa-admin.el` we need a writable directory as well.
> We also need the ability to run sub-processes.  Your `bwrap`
> implementation for GNU/Linux should allow that, AFAICT, but I can't =
tell
> if `darwin-sandbox-enter` also allows it.

Looks like it can be made to work.

Of course this whole exercise doesn't really touch the questions that =
really matter, such as whether it is practical for actual use.


--Apple-Mail=_E7692CE5-7A32-4E92-BD0A-A145CC42C55F
Content-Disposition: attachment;
	filename=0001-Add-macOS-sandboxing-bug-45198.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0001-Add-macOS-sandboxing-bug-45198.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=2003233ad9abb0c18bdbd00eb2cad42db8a252cafe=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20=
<mattiase@HIDDEN>=0ADate:=20Sat,=2017=20Apr=202021=2020:53:39=20+0200=0A=
Subject:=20[PATCH=201/2]=20Add=20macOS=20sandboxing=20(bug#45198)=0A=0A=
This=20is=20the=20corresponding=20low-level=20sandboxing=20facility=20=
corresponding=0Ato=20the=20recently=20added=20Seccomp=20for=20Linux.=20=20=
`darwin-sandbox-init`=20gives=0Adirect=20access=20to=20the=20system=20=
sandboxing=20call;=20`darwin--sandbox-enter`=0Ais=20a=20wrapper=20that=20=
takes=20a=20plist=20specifying=20directories=20under=20which=0Afiles=20=
can=20be=20read,=20written=20or=20executed.=20=20These=20should=20be=20=
considered=0Ainternal=20mechanisms=20for=20now.=0A=0A*=20=
lisp/darwin-fns.el:=20New=20file.=0A*=20lisp/loadup.el:=20Load=20it.=0A*=20=
src/sysdep.c=20(Fdarwin_sandbox_init):=20New=20function.=0A*=20=
test/lisp/darwin-fns-tests.el:=20New=20file.=0A---=0A=20=
lisp/darwin-fns.el=20=20=20=20=20=20=20=20=20=20=20=20|=2056=20=
+++++++++++++++++++++=0A=20lisp/loadup.el=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20|=20=202=20+=0A=20src/sysdep.c=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20|=2034=20+++++++++++++=0A=20=
test/lisp/darwin-fns-tests.el=20|=2091=20=
+++++++++++++++++++++++++++++++++++=0A=204=20files=20changed,=20183=20=
insertions(+)=0A=20create=20mode=20100644=20lisp/darwin-fns.el=0A=20=
create=20mode=20100644=20test/lisp/darwin-fns-tests.el=0A=0Adiff=20--git=20=
a/lisp/darwin-fns.el=20b/lisp/darwin-fns.el=0Anew=20file=20mode=20100644=0A=
index=200000000000..feba9739b5=0A---=20/dev/null=0A+++=20=
b/lisp/darwin-fns.el=0A@@=20-0,0=20+1,56=20@@=0A+;;;=20darwin-fns.el=20=
---=20Darwin-specific=20functions=20=20-*-=20lexical-binding:=20t=20-*-=0A=
+=0A+;;=20Copyright=20(C)=202021=20Free=20Software=20Foundation,=20Inc.=0A=
+=0A+;;=20This=20file=20is=20part=20of=20GNU=20Emacs.=0A+=0A+;;=20GNU=20=
Emacs=20is=20free=20software:=20you=20can=20redistribute=20it=20and/or=20=
modify=0A+;;=20it=20under=20the=20terms=20of=20the=20GNU=20General=20=
Public=20License=20as=20published=20by=0A+;;=20the=20Free=20Software=20=
Foundation,=20either=20version=203=20of=20the=20License,=20or=0A+;;=20=
(at=20your=20option)=20any=20later=20version.=0A+=0A+;;=20GNU=20Emacs=20=
is=20distributed=20in=20the=20hope=20that=20it=20will=20be=20useful,=0A=
+;;=20but=20WITHOUT=20ANY=20WARRANTY;=20without=20even=20the=20implied=20=
warranty=20of=0A+;;=20MERCHANTABILITY=20or=20FITNESS=20FOR=20A=20=
PARTICULAR=20PURPOSE.=20=20See=20the=0A+;;=20GNU=20General=20Public=20=
License=20for=20more=20details.=0A+=0A+;;=20You=20should=20have=20=
received=20a=20copy=20of=20the=20GNU=20General=20Public=20License=0A+;;=20=
along=20with=20GNU=20Emacs.=20=20If=20not,=20see=20=
<https://www.gnu.org/licenses/>.=0A+=0A+;;;=20Code:=0A+=0A+(defun=20=
darwin--sandbox-enter=20(spec)=0A+=20=20"Enter=20a=20sandbox=20only=20=
permitting=20actions=20described=20by=20SPEC.=0A+SPEC=20is=20a=20plist=20=
allowing=20the=20keys:=0A+`:read-dirs'=20=20--=20value=20is=20a=20list=20=
of=20directories=20in=20which=20reading=20is=20allowed.=0A+`:write-dirs'=20=
--=20value=20is=20a=20list=20of=20directories=20in=20which=20writing=20=
is=20allowed.=0A+`:exec-dirs'=20=20--=20value=20is=20a=20list=20of=20=
directories=20from=20which=20executables=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20can=20be=20run=20as=20subprocesses.=0A+Most=20other=20=
operations=20such=20as=20network=20access=20are=20disallowed.=0A=
+Existing=20open=20descriptors=20can=20still=20be=20used=20freely.=0A+=0A=
+This=20is=20not=20a=20supported=20interface=20and=20is=20for=20internal=20=
use=20only."=0A+=20=20(let=20((read-dirs=20(plist-get=20spec=20=
:read-dirs))=0A+=20=20=20=20=20=20=20=20(write-dirs=20(plist-get=20spec=20=
:write-dirs))=0A+=20=20=20=20=20=20=20=20(exec-dirs=20(plist-get=20spec=20=
:exec-dirs)))=0A+=20=20=20=20(darwin-sandbox-init=0A+=20=20=20=20=20=
(concat=0A+=20=20=20=20=20=20"(version=201)\n"=0A+=20=20=20=20=20=20=
"(deny=20default)\n"=0A+=20=20=20=20=20=20;;=20Emacs=20seems=20to=20need=20=
/dev/null;=20allowing=20it=20does=20no=20harm.=0A+=20=20=20=20=20=20=
"(allow=20file-read*=20(path=20\"/dev/null\"))\n"=0A+=20=20=20=20=20=20=
(mapconcat=20(lambda=20(dir)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(format=20"(allow=20file-read*=20(subpath=20%S))\n"=20=
dir))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20read-dirs=20=
"")=0A+=20=20=20=20=20=20(mapconcat=20(lambda=20(dir)=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20(format=20"(allow=20file-write*=20=
(subpath=20%S))\n"=20dir))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20write-dirs=20"")=0A+=20=20=20=20=20=20(mapconcat=20(lambda=20(dir)=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(format=20=
"(allow=20process-exec=20(subpath=20%S))\n"=20dir))=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20exec-dirs=20"")=0A+=20=20=20=20=20=20=
(and=20exec-dirs=0A+=20=20=20=20=20=20=20=20=20=20=20"(allow=20=
process-fork)\n")))))=0A+=0A+(provide=20'darwin-fns)=0A+=0A+;;;=20=
darwin-fns.el=20ends=20here=0Adiff=20--git=20a/lisp/loadup.el=20=
b/lisp/loadup.el=0Aindex=20158c02ecea..163b639640=20100644=0A---=20=
a/lisp/loadup.el=0A+++=20b/lisp/loadup.el=0A@@=20-325,6=20+325,8=20@@=0A=20=
=20=20=20=20=20=20(load=20"term/pc-win")=0A=20=20=20=20=20=20=20(load=20=
"ls-lisp")=0A=20=20=20=20=20=20=20(load=20"disp-table")))=20;=20needed=20=
to=20setup=20ibm-pc=20char=20set,=20see=20internal.el=0A+(if=20(eq=20=
system-type=20'darwin)=0A+=20=20=20=20(load=20"darwin-fns"))=0A=20(if=20=
(featurep=20'ns)=0A=20=20=20=20=20(progn=0A=20=20=20=20=20=20=20(load=20=
"term/common-win")=0Adiff=20--git=20a/src/sysdep.c=20b/src/sysdep.c=0A=
index=208eaee22498..79a1fad4da=20100644=0A---=20a/src/sysdep.c=0A+++=20=
b/src/sysdep.c=0A@@=20-4458,8=20+4458,42=20@@=20str_collate=20=
(Lisp_Object=20s1,=20Lisp_Object=20s2,=0A=20}=0A=20#endif=09/*=20=
WINDOWSNT=20*/=0A=20=0A+#ifdef=20DARWIN_OS=0A+=0A+/*=20This=20function=20=
prototype=20is=20not=20in=20the=20platform=20header=20files.=0A+=20=20=20=
See=20=
https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0=
.pdf=0A+=20=20=20and=20=
https://chromium.googlesource.com/chromium/src/+/master/sandbox/mac/seatbe=
lt_sandbox_design.md=20*/=0A+int=20sandbox_init_with_parameters(const=20=
char=20*profile,=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20uint64_t=20flags,=0A+=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20const=20char=20*const=20parameters[],=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20char=20**errorbuf);=0A+=0A+DEFUN=20("darwin-sandbox-init",=20=
Fdarwin_sandbox_init,=20Sdarwin_sandbox_init,=0A+=20=20=20=20=20=20=201,=20=
1,=200,=0A+=20=20=20=20=20=20=20doc:=20/*=20Enter=20a=20sandbox=20whose=20=
permitted=20access=20is=20curtailed=20by=20PROFILE.=0A+Already=20open=20=
descriptors=20can=20be=20used=20freely.=0A+PROFILE=20is=20a=20string=20=
in=20the=20macOS=20sandbox=20profile=20language,=0A+a=20set=20of=20rules=20=
in=20a=20Lisp-like=20syntax.=0A+=0A+This=20is=20not=20a=20supported=20=
interface=20and=20is=20for=20internal=20use=20only.=20*/)=0A+=20=20=
(Lisp_Object=20profile)=0A+{=0A+=20=20CHECK_STRING=20(profile);=0A+=20=20=
if=20(memchr=20(SSDATA=20(profile),=20'\0',=20SBYTES=20(profile)))=0A+=20=
=20=20=20error=20("NUL=20in=20sandbox=20profile");=0A+=20=20char=20*err=20=
=3D=20NULL;=0A+=20=20if=20(sandbox_init_with_parameters=20(SSDATA=20=
(profile),=200,=20NULL,=20&err)=20!=3D=200)=0A+=20=20=20=20error=20=
("sandbox=20error:=20%s",=20err);=0A+=20=20return=20Qnil;=0A+}=0A+=0A=
+#endif=09/*=20DARWIN_OS=20*/=0A+=0A=20void=0A=20syms_of_sysdep=20(void)=0A=
=20{=0A=20=20=20defsubr=20(&Sget_internal_run_time);=0A+#ifdef=20=
DARWIN_OS=0A+=20=20defsubr=20(&Sdarwin_sandbox_init);=0A+#endif=0A=20}=0A=
diff=20--git=20a/test/lisp/darwin-fns-tests.el=20=
b/test/lisp/darwin-fns-tests.el=0Anew=20file=20mode=20100644=0Aindex=20=
0000000000..fa0d58ac3d=0A---=20/dev/null=0A+++=20=
b/test/lisp/darwin-fns-tests.el=0A@@=20-0,0=20+1,91=20@@=0A+;;;=20=
darwin-fns-tests.el=20---=20tests=20for=20darwin-fns.el=20=20-*-=20=
lexical-binding:=20t=20-*-=0A+=0A+;;=20Copyright=20(C)=202021=20=20Free=20=
Software=20Foundation,=20Inc.=0A+=0A+;;=20This=20file=20is=20part=20of=20=
GNU=20Emacs.=0A+=0A+;;=20GNU=20Emacs=20is=20free=20software:=20you=20can=20=
redistribute=20it=20and/or=20modify=0A+;;=20it=20under=20the=20terms=20=
of=20the=20GNU=20General=20Public=20License=20as=20published=0A+;;=20by=20=
the=20Free=20Software=20Foundation,=20either=20version=203=20of=20the=20=
License,=0A+;;=20or=20(at=20your=20option)=20any=20later=20version.=0A+=0A=
+;;=20GNU=20Emacs=20is=20distributed=20in=20the=20hope=20that=20it=20=
will=20be=20useful,=20but=0A+;;=20WITHOUT=20ANY=20WARRANTY;=20without=20=
even=20the=20implied=20warranty=20of=0A+;;=20MERCHANTABILITY=20or=20=
FITNESS=20FOR=20A=20PARTICULAR=20PURPOSE.=20=20See=20the=20GNU=0A+;;=20=
General=20Public=20License=20for=20more=20details.=0A+=0A+;;=20You=20=
should=20have=20received=20a=20copy=20of=20the=20GNU=20General=20Public=20=
License=0A+;;=20along=20with=20GNU=20Emacs.=20=20If=20not,=20see=20=
<https://www.gnu.org/licenses/>.=0A+=0A+(require=20'ert)=0A+=0A+(defun=20=
darwin-fns-tests--run-emacs=20(expr1=20expr2)=0A+=20=20"Run=20Emacs=20in=20=
batch=20mode=20and=20evaluate=20EXPR1=20and=20EXPR2.=0A+Return=20=
(EXIT-STATUS=20.=20OUTPUT),=20where=20OUTPUT=20is=20stderr=20and=20=
stdout."=0A+=20=20(let=20((emacs=20(expand-file-name=20invocation-name=20=
invocation-directory))=0A+=20=20=20=20=20=20=20=20(process-environment=20=
nil))=0A+=20=20=20=20(with-temp-buffer=0A+=20=20=20=20=20=20(let=20((res=20=
(call-process=20emacs=20nil=20t=20nil=0A+=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"--quick"=20=
"--batch"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20(format=20"--eval=3D%S"=20expr1)=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20(format=20"--eval=3D%S"=20expr2))))=0A+=20=20=20=20=20=20=20=20=
(cons=20res=20(buffer-string))))))=0A+=0A+(ert-deftest=20=
darwin-fns-sandbox=20()=0A+=20=20(skip-unless=20(eq=20system-type=20=
'darwin))=0A+=20=20;;=20Test=20file=20reading=20and=20writing=20under=20=
various=20sandboxing=20conditions.=0A+=20=20(let*=20((some-text=20=
"abcdef")=0A+=20=20=20=20=20=20=20=20=20(new-text=20"ghijkl")=0A+=20=20=20=
=20=20=20=20=20=20(test-file=20(file-truename=20(make-temp-file=20=
"test")))=0A+=20=20=20=20=20=20=20=20=20(file-dir=20(file-name-directory=20=
test-file)))=0A+=20=20=20=20(unwind-protect=0A+=20=20=20=20=20=20=20=20=
(dolist=20(mode=20'(read=20write))=0A+=20=20=20=20=20=20=20=20=20=20=
(ert-info=20((symbol-name=20mode)=20:prefix=20"mode:=20")=0A+=20=20=20=20=
=20=20=20=20=20=20=20=20(dolist=20(sandbox=20'(allow-all=20deny-all=20=
allow-read))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20(ert-info=20=
((symbol-name=20sandbox)=20:prefix=20"sandbox:=20")=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20;;=20Prepare=20initial=20file=20contents.=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(with-temp-buffer=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(insert=20some-text)=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(write-file=20=
test-file))=0A+=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(let*=20=
((sandbox-form=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(pcase-exhaustive=20sandbox=0A+=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20('allow-all=20nil)=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20('deny-all=20'(darwin--sandbox-enter=20nil))=0A+=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20('allow-read=20=
`(darwin--sandbox-enter=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'(:read-dirs=20(,file-dir))))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20(action-form=0A+=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(pcase-exhaustive=20mode=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20('read=20`(progn=20(find-file-literally=20,test-file)=0A+=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20(message=20"OK:=20%s"=20=
(buffer-string))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20('write=20`(with-temp-buffer=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20(insert=20,new-text)=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20(write-file=20,test-file)))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20(allowed=20(or=20(eq=20sandbox=20=
'allow-all)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(and=20(eq=20sandbox=20=
'allow-read)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(eq=20=
mode=20'read))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(res-out=20(darwin-fns-tests--run-emacs=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20sandbox-form=20action-form))=0A+=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20(exit-status=20(car=20res-out))=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(output=20(cdr=20res-out))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20(file-contents=0A+=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20(with-temp-buffer=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(insert-file-contents-literally=20test-file)=0A+=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(buffer-string))))=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(if=20allowed=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(should=20=
(equal=20exit-status=200))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(should-not=20(equal=20exit-status=200)))=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20(when=20(eq=20mode=20'read)=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(if=20allowed=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(should=20(equal=20output=20(format=20"OK:=20%s\n"=20some-text)))=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(should-not=20=
(string-search=20some-text=20output))))=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20(should=20(equal=20file-contents=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20(if=20(and=20(eq=20mode=20'write)=20allowed)=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20new-text=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
some-text))))))))=0A+=0A+=20=20=20=20=20=20;;=20Clean=20up.=0A+=20=20=20=20=
=20=20(ignore-errors=20(delete-file=20test-file)))))=0A+=0A+=0A+(provide=20=
'darwin-fns-tests)=0A--=20=0A2.21.1=20(Apple=20Git-122.3)=0A=0A=

--Apple-Mail=_E7692CE5-7A32-4E92-BD0A-A145CC42C55F
Content-Disposition: attachment;
	filename=0002-platform-independent-sandbox-interface.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0002-platform-independent-sandbox-interface.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=20aa7780d2a40cf1da60ae236e9468cea9c36a8350=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20=
<mattiase@HIDDEN>=0ADate:=20Fri,=2017=20Sep=202021=2009:30:53=20+0200=0A=
Subject:=20[PATCH=202/2]=20platform-independent=20sandbox=20interface=0A=0A=
---=0A=20lisp/sandbox.el=20|=2091=20=
+++++++++++++++++++++++++++++++++++++++++++++++++=0A=201=20file=20=
changed,=2091=20insertions(+)=0A=20create=20mode=20100644=20=
lisp/sandbox.el=0A=0Adiff=20--git=20a/lisp/sandbox.el=20=
b/lisp/sandbox.el=0Anew=20file=20mode=20100644=0Aindex=20=
0000000000..589d25615a=0A---=20/dev/null=0A+++=20b/lisp/sandbox.el=0A@@=20=
-0,0=20+1,91=20@@=0A+;;;=20-*-=20lexical-binding:=20t=20-*-=0A+=0A=
+(require=20'cl-lib)=0A+=0A+(defconst=20sandbox-mechanism=0A+=20=20;;=20=
FIXME:=20make=20it=20a=20defcustom?=20What=20about=20other=20systems?=0A=
+=20=20(cond=20((eq=20system-type=20'darwin)=20'darwin)=0A+=20=20=20=20=20=
=20=20=20((eq=20system-type=20'gnu/linux)=20'bwrap)))=0A+=0A+(defun=20=
sandbox-available-p=20()=0A+=20=20"Non-nil=20if=20a=20sandboxing=20=
mechanism=20is=20available."=0A+=20=20;;=20FIXME:=20We=20should=20check=20=
for=20availability=20of=20bwrap=20etc.=0A+=20=20(not=20(null=20=
sandbox-mechanism)))=0A+=0A+(defun=20sandbox--program-args=20=
(sandbox-spec=20prog)=0A+=20=20"Return=20(PROGRAM=20.=20ARGS)=20for=20=
running=20PROG=20according=20to=20SANDBOX-SPEC."=0A+=20=20=
(pcase-exhaustive=20sandbox-mechanism=0A+=20=20=20=20('darwin=0A+=20=20=20=
=20=20(list=20prog=20"--eval"=0A+=20=20=20=20=20=20=20=20=20=20=20=
(prin1-to-string=20`(darwin--sandbox-enter=20',sandbox-spec))))=0A+=20=20=
=20=20('bwrap=0A+=20=20=20=20=20;;=20FIXME:=20with=20seccomp?=0A+=20=20=20=
=20=20(let*=20((read-dirs=20(plist-get=20sandbox-spec=20:read-dirs))=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20(write-dirs=20(plist-get=20sandbox-spec=20=
:write-dirs))=0A+=20=20=20=20=20=20=20=20=20=20=20=20(exec-dirs=20=
(plist-get=20sandbox-spec=20:exec-dirs))=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20(ro-dirs=20(cl-set-difference=0A+=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20(cl-union=20read-dirs=20exec-dirs=20:test=20=
#'equal)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20write-dirs=20:test=20#'equal)))=0A+=20=20=20=20=20=20=20`("bwrap"=0A+=20=
=20=20=20=20=20=20=20=20"--unshare-all"=0A+=20=20=20=20=20=20=20=20=20=
"--dev"=20"/dev"=0A+=20=20=20=20=20=20=20=20=20"--proc"=20"/proc"=0A+=20=20=
=20=20=20=20=20=20=20"--tmpfs"=20"/tmp"=0A+=20=20=20=20=20=20=20=20=20=
,@(mapcan=20(lambda=20(dir)=20(let=20((d=20(expand-file-name=20dir)))=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20(list=20"--ro-bind"=20d=20d)))=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20ro-dirs)=0A+=20=20=20=20=
=20=20=20=20=20,@(mapcan=20(lambda=20(dir)=20(let=20((d=20=
(expand-file-name=20dir)))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(list=20=
"--bind"=20d=20d)))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20write-dirs)=0A+=20=20=20=20=20=20=20=20=20,prog)))))=0A+=0A+(defun=20=
sandbox--emacs-command=20(sandbox-spec=20args)=0A+=20=20"Command=20and=20=
arguments=20for=20running=20Emacs=20with=20SANDBOX-SPEC=20and=20ARGS."=0A=
+=20=20(let*=20((emacs=20(expand-file-name=20invocation-name=20=
invocation-directory))=0A+=20=20=20=20=20=20=20=20=20(program-args=20=
(sandbox--program-args=20sandbox-spec=20emacs)))=0A+=20=20=20=20=
`(,@program-args=20"--batch"=20,@args)))=0A+=0A+(defun=20=
sandbox-run-emacs=20(sandbox-spec=20destination=20args)=0A+=20=20"Run=20=
sandboxed=20Emacs=20in=20batch=20mode,=20synchronously.=0A+SANDBOX-SPEC=20=
is=20a=20sandbox=20specification=20plist.=20=20Currently=20defined=20=
key:=0A+=20`:read-dirs'=20=20--=20the=20value=20is=20a=20list=20of=20=
directories=20that=20can=20be=20read=20from.=0A+=20`:write-dirs'=20--=20=
the=20value=20is=20a=20list=20of=20directories=20that=20can=20be=20=
written=20to.=0A+=20`:exec-dirs'=20=20--=20the=20value=20is=20a=20list=20=
of=20directories=20from=20which=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20executables=20can=20be=20run=20as=20subprocesses.=0A=
+DESTINATION=20is=20as=20in=20`call-process'.=0A+ARGS=20is=20a=20list=20=
of=20command-line=20arguments=20passed=20to=20the=20sandboxed=20Emacs.=0A=
+Return=20value=20is=20as=20in=20`call-process'.=0A+=0A+Depending=20on=20=
the=20platform,=20the=20sandbox=20restrictions=20do=20not=20necessarily=0A=
+take=20effect=20until=20Emacs=20has=20been=20initialised=20and=20loaded=20=
the=20site=20and=20user=0A+init=20files.=20=20If=20that=20is=20not=20=
desirable,=20suppress=20their=20use=20by=20adding=20the=0A+corresponding=20=
flags=20(eg=20\"-Q\")=20to=20ARGS."=0A+=20=20(let=20((command=20=
(sandbox--emacs-command=20sandbox-spec=20args)))=0A+=20=20=20=20(apply=20=
#'call-process=20(car=20command)=20nil=20destination=20nil=20(cdr=20=
command))))=0A+=0A+(defun=20sandbox-start-emacs=20(sandbox-spec=20params=20=
args)=0A+=20=20"Run=20sandboxed=20Emacs=20in=20batch=20mode,=20=
asynchronously.=0A+SANDBOX-SPEC=20is=20a=20sandbox=20specification=20=
plist.=20=20Currently=20defined=20key:=0A+=20`:read-dirs'=20=20--=20the=20=
value=20is=20a=20list=20of=20directories=20that=20can=20be=20read=20=
from.=0A+=20`:write-dirs'=20--=20the=20value=20is=20a=20list=20of=20=
directories=20that=20can=20be=20written=20to.=0A+=20`:exec-dirs'=20=20--=20=
the=20value=20is=20a=20list=20of=20directories=20from=20which=0A+=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20executables=20can=20be=20=
run=20as=20subprocesses.=0A+ARGS=20is=20a=20list=20of=20command-line=20=
arguments=20passed=20to=20the=20sandboxed=20Emacs.=0A+PARAMS=20is=20a=20=
plist=20of=20parameters=20passed=20to=20`make-process'.=20=20Do=20not=0A=
+=20=20supply=20`:command';=20it=20will=20be=20overridden=20by=20ARGS.=0A=
+Return=20value=20is=20as=20in=20`make-process'.=0A+=0A+Depending=20on=20=
the=20platform,=20the=20sandbox=20restrictions=20do=20not=20necessarily=0A=
+take=20effect=20until=20Emacs=20has=20been=20initialised=20and=20loaded=20=
the=20site=20and=20user=0A+init=20files.=20=20If=20that=20is=20not=20=
desirable,=20suppress=20their=20use=20by=20adding=20the=0A+corresponding=20=
flags=20(eg=20\"-Q\")=20to=20ARGS."=0A+=20=20(let*=20((command=20=
(sandbox--emacs-command=20sandbox-spec=20args))=0A+=20=20=20=20=20=20=20=20=
=20(params=20(copy-sequence=20params))=0A+=20=20=20=20=20=20=20=20=20=
(params=20(plist-put=20params=20:command=20command)))=0A+=20=20=20=20=
(unless=20(plist-member=20params=20:name)=0A+=20=20=20=20=20=20(setq=20=
params=20(plist-put=20params=20:name=20"emacs")))=0A+=20=20=20=20(unless=20=
(plist-member=20params=20:connection-type)=0A+=20=20=20=20=20=20(setq=20=
params=20(plist-put=20params=20:connection-type=20'pipe)))=0A+=20=20=20=20=
(apply=20#'make-process=20params)))=0A+=0A+(provide=20'sandbox)=0A--=20=0A=
2.21.1=20(Apple=20Git-122.3)=0A=0A=

--Apple-Mail=_E7692CE5-7A32-4E92-BD0A-A145CC42C55F--

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

Received: (at 45198) by debbugs.gnu.org; 17 Sep 2021 13:21:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 17 09:21:01 2021
Received: from localhost ([127.0.0.1]:58742 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mRDnZ-00035K-88
	for submit <at> debbugs.gnu.org; Fri, 17 Sep 2021 09:21:01 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65109)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1mRDnV-00034u-Tr
 for 45198 <at> debbugs.gnu.org; Fri, 17 Sep 2021 09:20:59 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6B4B1440BD5;
 Fri, 17 Sep 2021 09:20:52 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2EE68440B14;
 Fri, 17 Sep 2021 09:20:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1631884851;
 bh=msCJXSYa2G5tB/EVrFQiBdGg2p481JGMdCcwdZtoFOo=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=Jn5sqo/UeR3V+p1OFn/sQ70V8UjbzK2rYaRuxdgMcBWZJia2o5CwhTm444h2uqTFU
 CJiMsUnI+YV6DTof0Iz2xXRuX6r53DJpmf9dTjhjJGn7vOmXQ9Vq57L9oD7s+c8GdX
 XfyEd0UFpsFSenW8rzK+1E7sfmQxI9kfhtLAQqzUU0lFyGwULuPO7gioOjqsZcSDFb
 pQah7kvQPULN3rXveeaKs1BwBzbjTrN7dCTHh/EHCUxQrVOye4dQrjxbKcBg7cfvMb
 1cKideJxx5/FBILuCT4NUkN9/NPIWTFgKwezJITFu/qjXVgvjy7/Itd9FJx7ZlgLFY
 K2O8zjHwYY8hQ==
Received: from pastel (unknown [45.72.241.23])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E1873120320;
 Fri, 17 Sep 2021 09:20:50 -0400 (EDT)
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: <jwvfsu3732l.fsf-monnier+emacs@HIDDEN>
References: <DCB89188-A9D5-4A64-8DD2-BE1DD8A2B202@HIDDEN>
Date: Fri, 17 Sep 2021 09:20:50 -0400
In-Reply-To: <DCB89188-A9D5-4A64-8DD2-BE1DD8A2B202@HIDDEN> ("Mattias
 =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Fri, 17 Sep 2021 14:13:48
 +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.031 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: Alan Third <alan@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefan@HIDDEN>, Philipp <p.stephani2@HIDDEN>,
 =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
 Eli Zaretskii <eliz@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's basically versions of `call-process` and `make-process` specialised for
> running batch-mode Emacs in a sandbox. The attached patch is a straw man
> proposal but that should serve as a starting point for agreement on what the
> interface might look like.

For `elpa-admin.el` we need a writable directory as well.
We also need the ability to run sub-processes.  Your `bwrap`
implementation for GNU/Linux should allow that, AFAICT, but I can't tell
if `darwin-sandbox-enter` also allows it.


        Stefan

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

Received: (at 45198) by debbugs.gnu.org; 17 Sep 2021 12:14:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 17 08:14:00 2021
Received: from localhost ([127.0.0.1]:58687 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mRCkh-0001Oa-QE
	for submit <at> debbugs.gnu.org; Fri, 17 Sep 2021 08:14:00 -0400
Received: from mail18c50.megamailservers.eu ([91.136.10.28]:40944)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1mRCkc-0001OM-2m
 for 45198 <at> debbugs.gnu.org; Fri, 17 Sep 2021 08:13:58 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1631880831;
 bh=zdOhtTAeZaVdWo1v/MJiaZgMz9u8APKlXKfO9uFY/vc=;
 h=From:Subject:Date:Cc:To:From;
 b=T5y+qW+A/AdccwImx9+NXTVr6TzwBz/+dDxApLHYRv1nsdetA3mTzSpAV9hpwppVc
 1PlFv/tMMugd+zRpirkwXQ/CJSYo2IpPubfk6fh+ezZdfedjMe8irsv4X9nfqZaPx/
 Gd3U96MVm5hUcMdQTU/ysDBi9xeh69W2EZy+ZIuA=
Feedback-ID: mattiase@HIDDEN
Received: from [192.168.0.4] (c188-150-171-71.bredband.tele2.se
 [188.150.171.71]) (authenticated bits=0)
 by mail18c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 18HCDmuw001024; 
 Fri, 17 Sep 2021 12:13:50 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_75BBA58D-B918-40D7-B1FE-10C494228A76"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-Id: <DCB89188-A9D5-4A64-8DD2-BE1DD8A2B202@HIDDEN>
Date: Fri, 17 Sep 2021 14:13:48 +0200
To: Philipp <p.stephani2@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.21)
X-CTCH-RefID: str=0001.0A742F1A.6144867F.0062, 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.4 cv=etO8cqlX c=1 sm=1 tr=0 ts=6144867f
 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17
 a=M51BFTxLslgA:10 a=_WudpDD8Swmy5rFBtbIA:9 a=CjuIK1q_8ugA:10
 a=2YU-EQram26tckInahMA:9 a=B2y7HmGcmWMA:10 a=tclcd6dtLQvEqt9_mmAA:9
X-Origin-Country: SE
X-Spam-Score: 3.7 (+++)
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: So far the discussion has been focussed on platform-dependent
 low-level sandbox implementation. I took a stab at writing something that
 can be used by portable code. It's basically versions of `call-process` and
 `make-process` specialised for running batch-mode Emacs in a sandbox. The
 attached patch is a straw man proposal but that should serve as a starting
 point [...] 
 Content analysis details:   (3.7 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 T_SPF_TEMPERROR        SPF: test of record failed (temperror)
 3.7 FAKE_REPLY_B           No description available.
X-Debbugs-Envelope-To: 45198
Cc: Alan Third <alan@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
 Eli Zaretskii <eliz@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: 3.7 (+++)
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:  So far the discussion has been focussed on platform-dependent
    low-level sandbox implementation. I took a stab at writing something that
    can be used by portable code. It's basically versions of `call-process` and
    `make-process` specialised for running batch-mode Emacs in a sandbox. The
    attached patch is a straw man proposal but that should serve as a starting
    point [...] 
 
 Content analysis details:   (3.7 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.7 FAKE_REPLY_B           No description available.


--Apple-Mail=_75BBA58D-B918-40D7-B1FE-10C494228A76
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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

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

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

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

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

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


--Apple-Mail=_75BBA58D-B918-40D7-B1FE-10C494228A76
Content-Disposition: attachment;
	filename=0001-platform-independent-sandbox-interface.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0001-platform-independent-sandbox-interface.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=201dfea4588286ec4177619bd5d20502803a98c4c0=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20=
<mattiase@HIDDEN>=0ADate:=20Fri,=2017=20Sep=202021=2009:30:53=20+0200=0A=
Subject:=20[PATCH]=20platform-independent=20sandbox=20interface=0A=0A---=0A=
=20lisp/sandbox.el=20|=2077=20=
+++++++++++++++++++++++++++++++++++++++++++++++++=0A=201=20file=20=
changed,=2077=20insertions(+)=0A=20create=20mode=20100644=20=
lisp/sandbox.el=0A=0Adiff=20--git=20a/lisp/sandbox.el=20=
b/lisp/sandbox.el=0Anew=20file=20mode=20100644=0Aindex=20=
0000000000..a8069d59c7=0A---=20/dev/null=0A+++=20b/lisp/sandbox.el=0A@@=20=
-0,0=20+1,77=20@@=0A+;;;=20-*-=20lexical-binding:=20t=20-*-=0A+=0A=
+(defconst=20sandbox-mechanism=0A+=20=20;;=20FIXME:=20make=20it=20a=20=
defcustom?=20What=20about=20other=20systems?=0A+=20=20(cond=20((eq=20=
system-type=20'darwin)=20'darwin)=0A+=20=20=20=20=20=20=20=20((eq=20=
system-type=20'gnu/linux)=20'bwrap)))=0A+=0A+(defun=20=
sandbox-available-p=20()=0A+=20=20"Non-nil=20if=20a=20sandboxing=20=
mechanism=20is=20available."=0A+=20=20;;=20FIXME:=20We=20should=20check=20=
for=20availability=20of=20bwrap=20etc.=0A+=20=20(not=20(null=20=
sandbox-mechanism)))=0A+=0A+(defun=20sandbox--program-args=20=
(sandbox-spec=20prog)=0A+=20=20"Return=20(PROGRAM=20.=20ARGS)=20for=20=
running=20PROG=20according=20to=20SANDBOX-SPEC."=0A+=20=20(let=20=
((allow-read-dirs=20(plist-get=20sandbox-spec=20:allow-read-dirs)))=0A+=20=
=20=20=20;;=20FIXME:=20Would=20`:allow-write-dirs'=20make=20sense=20and=20=
be=20useful?=0A+=20=20=20=20(pcase-exhaustive=20sandbox-mechanism=0A+=20=20=
=20=20=20=20('darwin=0A+=20=20=20=20=20=20=20(list=20prog=20"--eval"=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20(prin1-to-string=20=
`(darwin-sandbox-enter=20',allow-read-dirs))))=0A+=20=20=20=20=20=20=
('bwrap=0A+=20=20=20=20=20=20=20;;=20FIXME:=20with=20seccomp?=0A+=20=20=20=
=20=20=20=20`("bwrap"=0A+=20=20=20=20=20=20=20=20=20"--unshare-all"=0A+=20=
=20=20=20=20=20=20=20=20"--dev"=20"/dev"=0A+=20=20=20=20=20=20=20=20=20=
"--proc"=20"/proc"=0A+=20=20=20=20=20=20=20=20=20"--tmpfs"=20"/tmp"=0A+=20=
=20=20=20=20=20=20=20=20,@(mapcan=20(lambda=20(dir)=20(let=20((d=20=
(expand-file-name=20dir)))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(list=20=
"--ro-bind"=20d=20d)))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20allow-read-dirs)=0A+=20=20=20=20=20=20=20=20=20,prog)))))=0A+=0A=
+(defun=20sandbox--emacs-command=20(sandbox-spec=20args)=0A+=20=20(let*=20=
((emacs=20(expand-file-name=20invocation-name=20invocation-directory))=0A=
+=20=20=20=20=20=20=20=20=20(program-args=20(sandbox--program-args=20=
sandbox-spec=20emacs)))=0A+=20=20=20=20`(,@program-args=20"--batch"=20=
,@args)))=0A+=0A+(defun=20sandbox-run-emacs=20(sandbox-spec=20=
destination=20args)=0A+=20=20"Run=20sandboxed=20Emacs=20in=20batch=20=
mode,=20synchronously.=0A+SANDBOX-SPEC=20is=20a=20sandbox=20=
specification=20plist.=20=20Currently=20defined=20key:=0A+=20=
`:allow-read-dirs'=20--=20the=20value=20is=20a=20list=20of=20directories=20=
that=20can=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20be=20read=20from=20(but=20not=20written=20to).=0A+DESTINATION=20=
is=20as=20in=20`call-process'.=0A+ARGS=20is=20a=20list=20of=20=
command-line=20arguments=20passed=20to=20the=20sandboxed=20Emacs.=0A=
+Return=20value=20is=20as=20in=20`call-process'.=0A+=0A+Depending=20on=20=
the=20platform,=20the=20sandbox=20restrictions=20do=20not=20necessarily=0A=
+take=20effect=20until=20Emacs=20has=20been=20initialised=20and=20loaded=20=
the=20site=20and=20user=0A+init=20files.=20=20If=20that=20is=20not=20=
desirable,=20suppress=20their=20use=20by=20adding=20the=0A+corresponding=20=
flags=20(eg=20\"-Q\")=20to=20ARGS."=0A+=20=20(let=20((command=20=
(sandbox--emacs-command=20sandbox-spec=20args)))=0A+=20=20=20=20(apply=20=
#'call-process=20(car=20command)=20nil=20destination=20nil=20(cdr=20=
command))))=0A+=0A+(defun=20sandbox-start-emacs=20(sandbox-spec=20params=20=
args)=0A+=20=20"Run=20sandboxed=20Emacs=20in=20batch=20mode,=20=
asynchronously.=0A+SANDBOX-SPEC=20is=20a=20sandbox=20specification=20=
plist.=20=20Currently=20defined=20key:=0A+=20`:allow-read-dirs'=20--=20=
the=20value=20is=20a=20list=20of=20directories=20that=20can=0A+=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20be=20read=20=
from=20(but=20not=20written=20to).=0A+ARGS=20is=20a=20list=20of=20=
command-line=20arguments=20passed=20to=20the=20sandboxed=20Emacs.=0A=
+PARAMS=20is=20a=20plist=20of=20parameters=20passed=20to=20=
`make-process'.=20=20Do=20not=0A+=20=20supply=20`:command';=20it=20will=20=
be=20overridden=20by=20ARGS.=0A+Return=20value=20is=20as=20in=20=
`make-process'.=0A+=0A+Depending=20on=20the=20platform,=20the=20sandbox=20=
restrictions=20do=20not=20necessarily=0A+take=20effect=20until=20Emacs=20=
has=20been=20initialised=20and=20loaded=20the=20site=20and=20user=0A=
+init=20files.=20=20If=20that=20is=20not=20desirable,=20suppress=20their=20=
use=20by=20adding=20the=0A+corresponding=20flags=20(eg=20\"-Q\")=20to=20=
ARGS."=0A+=20=20(let*=20((command=20(sandbox--emacs-command=20=
sandbox-spec=20args))=0A+=20=20=20=20=20=20=20=20=20(params=20=
(copy-sequence=20params))=0A+=20=20=20=20=20=20=20=20=20(params=20=
(plist-put=20params=20:command=20command)))=0A+=20=20=20=20(unless=20=
(plist-member=20params=20:name)=0A+=20=20=20=20=20=20(setq=20params=20=
(plist-put=20params=20:name=20"emacs")))=0A+=20=20=20=20(unless=20=
(plist-member=20params=20:connection-type)=0A+=20=20=20=20=20=20(setq=20=
params=20(plist-put=20params=20:connection-type=20'pipe)))=0A+=20=20=20=20=
(apply=20#'make-process=20params)))=0A+=0A+(provide=20'sandbox)=0A--=20=0A=
2.21.1=20(Apple=20Git-122.3)=0A=0A=

--Apple-Mail=_75BBA58D-B918-40D7-B1FE-10C494228A76
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii




--Apple-Mail=_75BBA58D-B918-40D7-B1FE-10C494228A76--

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

Received: (at 45198) by debbugs.gnu.org; 5 Jul 2021 19:12:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 05 15:12:48 2021
Received: from localhost ([127.0.0.1]:46672 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m0U1Q-0003ji-AR
	for submit <at> debbugs.gnu.org; Mon, 05 Jul 2021 15:12:48 -0400
Received: from mail-wr1-f46.google.com ([209.85.221.46]:37732)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1m0U1O-0003jU-3P
 for 45198 <at> debbugs.gnu.org; Mon, 05 Jul 2021 15:12:46 -0400
Received: by mail-wr1-f46.google.com with SMTP id i94so23249309wri.4
 for <45198 <at> debbugs.gnu.org>; Mon, 05 Jul 2021 12:12:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=ncFwJWnsSClosJvOKRMYJlhpIUUNxuLOLs7ScB0vtsA=;
 b=sT7mQgLF/ikOJZtO1nIzzLJADcIIY/GrRpveEHiAuz14uKr5VpJ7kDo90MNYzxBrQ0
 f/SI5yfAMgeTyji8GVkl7keXADW/K78+MfbQyjic+NlWQcwNvU88rXHeeQbe+9oGcDbZ
 EL5lbWOYM3QcSUFfd7b2Y0dwVRTaMsRw+1OJt56eJKA17tT2c63DjoSVTLE2WmgWgIHA
 BbRFR2+3TOsiy22YnzX9++l50eBGScBfYO7lvfdfj+xNS/fQuQ9OhxHC/aC0VgXEZ5Iz
 knOvr6MgBqlp0UZr9LJZx+WAKX+p/CTMF1eP6TPe/cqzwCII6Ll/QJtdErdLrwVQ28/h
 wc7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=ncFwJWnsSClosJvOKRMYJlhpIUUNxuLOLs7ScB0vtsA=;
 b=eL6c02C6QYxvBPrzkGxsZJgtIJaONTj+bYgyELkz71YYtar8Gq1UI3U6D7fl/tanP/
 1hZ5lYEaQoJmGtooC/Qf5eFI41iK9xOjibXd9jK8By+tvxMUUZ6LT5CzmxOjjKIS+4Dn
 1FIF5GY+JGE1CsZz+5IY8RTX1WBHQf5Segdw10cfYjQn7qE+5hN2HAKc9qZXB/HAP6oM
 CoZOVFSxVVizBmtSZoPym2mFL9fztOMJ6o/40EKPkR4S1c6O/6WFla15LzQ1SP/ijII+
 aGRiIpl14/Zm9ws9BD5iOqAr+u2F4MhgpJA1iL3/mZUbQwZ6GSIXy64f8esPlucH7jqu
 qr0Q==
X-Gm-Message-State: AOAM532v2965CLIgtWVX54f096a/Cea085DfrjxmkNrDyGCoK45dgtX0
 3KMZNpzmZzCci7V7GSnDpV0=
X-Google-Smtp-Source: ABdhPJzINWIMMPIWuPmtp2CA2y5btG8K1l3XFL2Bw5+fR9ADUIh1wIhJOjnfCIs23VOGYHskK1cQJQ==
X-Received: by 2002:a5d:4282:: with SMTP id k2mr12469261wrq.6.1625512360399;
 Mon, 05 Jul 2021 12:12:40 -0700 (PDT)
Received: from smtpclient.apple ([46.128.198.100])
 by smtp.gmail.com with ESMTPSA id a186sm350802wme.25.2021.07.05.12.12.39
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 05 Jul 2021 12:12:40 -0700 (PDT)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: Philipp <p.stephani2@HIDDEN>
In-Reply-To: <jwvlf9f3c7i.fsf-monnier+emacs@HIDDEN>
Date: Mon, 5 Jul 2021 21:12:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDC57E2E-D7A1-4DCA-BFBD-C182589F0FCD@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <jwva6pwalxc.fsf-monnier+emacs@HIDDEN> <83o8ecvnok.fsf@HIDDEN>
 <jwv5z0k7qeg.fsf-monnier+emacs@HIDDEN> <83lf9gvktv.fsf@HIDDEN>
 <jwv7dl069cy.fsf-monnier+emacs@HIDDEN> <83im4kvi4e.fsf@HIDDEN>
 <jwv1rb864yg.fsf-monnier+emacs@HIDDEN> <83blacun30.fsf@HIDDEN>
 <jwvlf9f3c7i.fsf-monnier+emacs@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>,
 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
 Eli Zaretskii <eliz@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 18.04.2021 um 16:25 schrieb Stefan Monnier =
<monnier@HIDDEN>:
>=20
>>> The whole point of the sandboxing exercise is so as to be able to =
have
>>> flymake-mode in the hook without exposing yourself to
>>> these vulnerabilities.
>>=20
>> So we are going to introduce all this non-trivial machinery into =
Emacs
>> just to solve the Flymake use case?  Is that reasonable from the
>> project management POV, in your eyes?
>=20
> To the extent that this machinery will only be used by those rare =
places
> that need it (e.g. flymake), yes, as long as the low-level interface
> (e.g. the code that added the support for the `--seccomp` argument) is
> simple enough.
>=20
> BTW, in the context of GNU/Linux, an alternative to `--seccomp` is to
> require the `bwrap` tool (that's what I use in the `elpa-admin.el`
> scripts to run makefile rules from ELPA packages).
>=20

I wouldn't call it an alternative, they are rather complementary =
approaches, and I think we should require both for a sandbox that we =
consider "hard enough".  The --seccomp flag doesn't set up namespaces; =
that's rather subtle and best done out-of-process by a dedicated tool =
like bwrap.  On the other hand, setting up a seccomp filter =
out-of-process has the disadvantage that it needs to allow execve, =
thereby increasing the attack surface quite a bit.  The sandboxing I'd =
have in mind would be a combination of bwrap (with namespaces and a =
seccomp filter that allows execve) and Emacs's own seccomp filter =
(banning execve).=

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

Received: (at 45198) by debbugs.gnu.org; 19 Apr 2021 15:42:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 19 11:42:52 2021
Received: from localhost ([127.0.0.1]:51780 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYW32-0001Z1-GW
	for submit <at> debbugs.gnu.org; Mon, 19 Apr 2021 11:42:52 -0400
Received: from mail1453c50.megamailservers.eu ([91.136.14.53]:42084
 helo=mail266c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1lYW31-0001Yo-33
 for 45198 <at> debbugs.gnu.org; Mon, 19 Apr 2021 11:42:51 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1618846923;
 bh=xBd6e47VXmRBCuDBMZ53UfFjnQpv+/r6mf8FcgoaPTE=;
 h=From:Subject:Date:In-Reply-To:Cc:To:References:From;
 b=Ue47454X4EDzE/vfa/SfAgkDR7iyY2CZgbNAp1UlB+76LcUL875xncEznGKhVjcE4
 W9rcn9GVVcTDioKZ+FaTCMXvxlwNjHk5I4Wg3kmFgriHBJm8eQFw7Rcd6FGuaVi1HC
 4T6lI0bhKA6D1w1Cjhj95C7fEDGqsksdnfcA9vwY=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-b952e353.032-75-73746f71.bbcust.telenor.se
 [83.227.82.185]) (authenticated bits=0)
 by mail266c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 13JFfwNl003772; 
 Mon, 19 Apr 2021 15:42:00 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Message-Id: <F61CF0B6-6AB0-415C-BAD4-54273D0DD476@HIDDEN>
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_59FECC85-2A93-4A38-B1A5-7709DA915415"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Date: Mon, 19 Apr 2021 17:41:58 +0200
In-Reply-To: <E967667D-698C-47FE-9E95-429C30C83907@HIDDEN>
To: Philipp <p.stephani2@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN>
 <jwvim4k6ade.fsf-monnier+emacs@HIDDEN>
 <78F41D0B-D2F6-444C-9B5C-9C50CFF2CFBD@HIDDEN>
 <E967667D-698C-47FE-9E95-429C30C83907@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A742F16.607DA4CA.0088, 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=VISjYOHX c=1 sm=1 tr=0 a=von4qPfY+hyqc0zmWf0tYQ==:117
 a=von4qPfY+hyqc0zmWf0tYQ==:17 a=M51BFTxLslgA:10 a=pGLkceISAAAA:8
 a=P_jWLAUnFZnPBouWQNAA:9 a=CjuIK1q_8ugA:10 a=2i1jUgeGfihAGWfHL1kA:9
 a=B2y7HmGcmWMA: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: 17 apr. 2021 kl. 21.42 skrev Philipp <p.stephani2@HIDDEN>:
 >> --- a/lisp/subr.el > > Should this maybe be in a platform-specific file
 such as ns-fns.el (like dos-fns.el, w32-fns.el)? Yes,
 and thank you for noticing. Now moved. 
 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: alan@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@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 (/)


--Apple-Mail=_59FECC85-2A93-4A38-B1A5-7709DA915415
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


17 apr. 2021 kl. 21.42 skrev Philipp <p.stephani2@HIDDEN>:

>> --- a/lisp/subr.el
>=20
> Should this maybe be in a platform-specific file such as ns-fns.el =
(like dos-fns.el, w32-fns.el)?

Yes, and thank you for noticing. Now moved.

> I don't think we use the "darwin-" prefix anywhere else in Emacs.  =
Maybe use a "ns-" prefix.

As Alan correctly noted this has nothing with NS to do per se, so I'm =
staying with darwin- for now.

> Also I think such internal functions commonly have an "internal" piece =
somewhere in their name, e.g. "ns-enter-sandbox-internal".

Maybe, but there is already a platform-specific prefix and a clear note =
in the doc string that it's internal. Doesn't that suffice?

>> +    (darwin-sandbox-init
>=20
> Can you also refer to the documents listed below, so that readers =
aren't wondering what this syntax means?

Thank you but that sounds unlikely since the PROFILE argument is =
described as SBPL in the function doc string.

>> +     (concat "(version 1)\n"
>=20
> Since this uses Lisp syntax, maybe use (prin1-to-string `(...))?

I'd rather not, since it's not exactly Emacs Lisp syntax. I'd like to =
avoiding conflating the two as far as possible. However...

>> +                          (format "(allow file-read* (subpath =
%S))\n" dir))
>=20
> Are you sure that the string quoting syntaxes are compatible?

It had me concerned when I wrote it too but it didn't seem possible to =
cause a false positive that way -- false negatives (access denial) at =
worst. In particular, names containing backslashes or double quotes work =
correctly.

>> +       doc: /* Enter a sandbox whose permitted access is curtailed =
by PROFILE.
>> +Already open descriptors can be used freely.
>> +PROFILE is a string in the macOS sandbox profile language,
>> +a set of rules in a Lisp-like syntax.
>=20
> I'd also refer to the Chromium document here, otherwise C-h f for this =
function won't be very useful.

I wouldn't worry -- an Emacs developer who doesn't already know it is =
more likely to duckduckgo "macos sandbox profile language" and get an =
up-to-date reference.

>> +  if (sandbox_init_with_parameters (SSDATA (profile), 0, NULL, &err) =
!=3D 0)
>=20
> If you're using SSDATA, better check that the string doesn't contain =
embedded null bytes.

There is really no way that that could ever be a problem but I added a =
check just in case.

> Also does this need to be encoded somehow?  What happens if the string =
contains non-Unicode characters like raw bytes?

Then there will be false negatives (permissions not granted) or syntax =
errors. This is just a system call wrapper; the caller is responsible =
for using reasonable arguments.

>> +    error ("sandbox error: %s", err);
>=20
> This looks like an error that clients could handle, so I'd signal a =
specific error symbol here.

That error just indicates a programming mistake. Nobody is going to =
handle it.

>> diff --git a/test/src/emacs-tests.el b/test/src/emacs-tests.el
>=20
> This should probably be in subr-tests.el since it tests a function in =
subr.el.

Right again, moved to a new file.

> I like tests that are somewhat repetitive but more decoupled and =
easier to read better than tests with factored-out assertions.

There is merit to such a style but the more important concern in this =
case is to avoid false positives and negatives, and make the tests =
robust in that regard.

It is very easy to make a mistake that renders a test meaningless, =
especially when testing a mechanism that does not alter the value of a =
computation but merely allows it to proceed or causes it to fail. The =
test has now been rewritten in a kind of oracular-combinatorial style =
which is effective in these situations. Doing so also improved coverage.

Thank you very much for your review and comments! I'd like to push the =
resulting patch but perhaps it and the rest of the sandbox development =
should go into a separate branch?


--Apple-Mail=_59FECC85-2A93-4A38-B1A5-7709DA915415
Content-Disposition: attachment;
	filename=0001-Add-macOS-sandboxing-bug-45198.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0001-Add-macOS-sandboxing-bug-45198.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=20c5006dc5260f547ff132fd42c580ea0e0fb227a7=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20=
<mattiase@HIDDEN>=0ADate:=20Sat,=2017=20Apr=202021=2020:53:39=20+0200=0A=
Subject:=20[PATCH]=20Add=20macOS=20sandboxing=20(bug#45198)=0A=0AThis=20=
is=20the=20corresponding=20low-level=20sandboxing=20facility=20=
corresponding=0Ato=20the=20recently=20added=20Seccomp=20for=20Linux.=20=20=
`darwin-sandbox-init`=20gives=0Adirect=20access=20to=20the=20system=20=
sandboxing=20call;=20`darwin-sandbox-enter`=20is=0Aa=20wrapper=20that=20=
takes=20a=20list=20of=20directories=20under=20which=20files=20can=20be=0A=
read.=20=20These=20should=20be=20considered=20internal=20mechanisms=20=
for=20now.=0A=0A*=20lisp/darwin-fns.el:=20New=20file.=0A*=20=
lisp/loadup.el:=20Load=20it.=0A*=20src/sysdep.c=20=
(Fdarwin_sandbox_init):=20New=20function.=0A*=20=
test/lisp/darwin-fns-tests.el:=20New=20file.=0A---=0A=20=
lisp/darwin-fns.el=20=20=20=20=20=20=20=20=20=20=20=20|=2040=20=
++++++++++++++++=0A=20lisp/loadup.el=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20|=20=202=20+=0A=20src/sysdep.c=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20|=2034=20+++++++++++++=0A=20=
test/lisp/darwin-fns-tests.el=20|=2090=20=
+++++++++++++++++++++++++++++++++++=0A=204=20files=20changed,=20166=20=
insertions(+)=0A=20create=20mode=20100644=20lisp/darwin-fns.el=0A=20=
create=20mode=20100644=20test/lisp/darwin-fns-tests.el=0A=0Adiff=20--git=20=
a/lisp/darwin-fns.el=20b/lisp/darwin-fns.el=0Anew=20file=20mode=20100644=0A=
index=200000000000..e45aaa0c4e=0A---=20/dev/null=0A+++=20=
b/lisp/darwin-fns.el=0A@@=20-0,0=20+1,40=20@@=0A+;;;=20darwin-fns.el=20=
---=20Darwin-specific=20functions=20=20-*-=20lexical-binding:=20t=20-*-=0A=
+=0A+;;=20Copyright=20(C)=202021=20Free=20Software=20Foundation,=20Inc.=0A=
+=0A+;;=20This=20file=20is=20part=20of=20GNU=20Emacs.=0A+=0A+;;=20GNU=20=
Emacs=20is=20free=20software:=20you=20can=20redistribute=20it=20and/or=20=
modify=0A+;;=20it=20under=20the=20terms=20of=20the=20GNU=20General=20=
Public=20License=20as=20published=20by=0A+;;=20the=20Free=20Software=20=
Foundation,=20either=20version=203=20of=20the=20License,=20or=0A+;;=20=
(at=20your=20option)=20any=20later=20version.=0A+=0A+;;=20GNU=20Emacs=20=
is=20distributed=20in=20the=20hope=20that=20it=20will=20be=20useful,=0A=
+;;=20but=20WITHOUT=20ANY=20WARRANTY;=20without=20even=20the=20implied=20=
warranty=20of=0A+;;=20MERCHANTABILITY=20or=20FITNESS=20FOR=20A=20=
PARTICULAR=20PURPOSE.=20=20See=20the=0A+;;=20GNU=20General=20Public=20=
License=20for=20more=20details.=0A+=0A+;;=20You=20should=20have=20=
received=20a=20copy=20of=20the=20GNU=20General=20Public=20License=0A+;;=20=
along=20with=20GNU=20Emacs.=20=20If=20not,=20see=20=
<https://www.gnu.org/licenses/>.=0A+=0A+;;;=20Code:=0A+=0A+(defun=20=
darwin-sandbox-enter=20(dirs)=0A+=20=20"Enter=20a=20sandbox=20only=20=
permitting=20reading=20files=20under=20DIRS.=0A+DIRS=20is=20a=20list=20=
of=20directory=20names.=20=20Most=20other=20operations=20such=20as=0A=
+writing=20files=20and=20network=20access=20are=20disallowed.=0A=
+Existing=20open=20descriptors=20can=20still=20be=20used=20freely.=0A+=0A=
+This=20is=20not=20a=20supported=20interface=20and=20is=20for=20internal=20=
use=20only."=0A+=20=20(darwin-sandbox-init=0A+=20=20=20(concat=20=
"(version=201)\n"=0A+=20=20=20=20=20=20=20=20=20=20=20"(deny=20=
default)\n"=0A+=20=20=20=20=20=20=20=20=20=20=20;;=20Emacs=20seems=20to=20=
need=20/dev/null;=20allowing=20it=20does=20no=20harm.=0A+=20=20=20=20=20=20=
=20=20=20=20=20"(allow=20file-read*=20(path=20\"/dev/null\"))\n"=0A+=20=20=
=20=20=20=20=20=20=20=20=20(mapconcat=20(lambda=20(dir)=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(format=20=
"(allow=20file-read*=20(subpath=20%S))\n"=20dir))=0A+=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20dirs=20""))))=0A+=0A=
+(provide=20'darwin-fns)=0A+=0A+;;;=20darwin-fns.el=20ends=20here=0Adiff=20=
--git=20a/lisp/loadup.el=20b/lisp/loadup.el=0Aindex=20=
d6cfcd6fc8..a6a7251d4b=20100644=0A---=20a/lisp/loadup.el=0A+++=20=
b/lisp/loadup.el=0A@@=20-324,6=20+324,8=20@@=0A=20=20=20=20=20=20=20=
(load=20"term/pc-win")=0A=20=20=20=20=20=20=20(load=20"ls-lisp")=0A=20=20=
=20=20=20=20=20(load=20"disp-table")))=20;=20needed=20to=20setup=20=
ibm-pc=20char=20set,=20see=20internal.el=0A+(if=20(eq=20system-type=20=
'darwin)=0A+=20=20=20=20(load=20"darwin-fns"))=0A=20(if=20(featurep=20=
'ns)=0A=20=20=20=20=20(progn=0A=20=20=20=20=20=20=20(load=20=
"term/common-win")=0Adiff=20--git=20a/src/sysdep.c=20b/src/sysdep.c=0A=
index=20d940acc4e0..4ea1f0050a=20100644=0A---=20a/src/sysdep.c=0A+++=20=
b/src/sysdep.c=0A@@=20-4286,8=20+4286,42=20@@=20str_collate=20=
(Lisp_Object=20s1,=20Lisp_Object=20s2,=0A=20}=0A=20#endif=09/*=20=
WINDOWSNT=20*/=0A=20=0A+#ifdef=20DARWIN_OS=0A+=0A+/*=20This=20function=20=
prototype=20is=20not=20in=20the=20platform=20header=20files.=0A+=20=20=20=
See=20=
https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0=
.pdf=0A+=20=20=20and=20=
https://chromium.googlesource.com/chromium/src/+/master/sandbox/mac/seatbe=
lt_sandbox_design.md=20*/=0A+int=20sandbox_init_with_parameters(const=20=
char=20*profile,=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20uint64_t=20flags,=0A+=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20const=20char=20*const=20parameters[],=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20char=20**errorbuf);=0A+=0A+DEFUN=20("darwin-sandbox-init",=20=
Fdarwin_sandbox_init,=20Sdarwin_sandbox_init,=0A+=20=20=20=20=20=20=201,=20=
1,=200,=0A+=20=20=20=20=20=20=20doc:=20/*=20Enter=20a=20sandbox=20whose=20=
permitted=20access=20is=20curtailed=20by=20PROFILE.=0A+Already=20open=20=
descriptors=20can=20be=20used=20freely.=0A+PROFILE=20is=20a=20string=20=
in=20the=20macOS=20sandbox=20profile=20language,=0A+a=20set=20of=20rules=20=
in=20a=20Lisp-like=20syntax.=0A+=0A+This=20is=20not=20a=20supported=20=
interface=20and=20is=20for=20internal=20use=20only.=20*/)=0A+=20=20=
(Lisp_Object=20profile)=0A+{=0A+=20=20CHECK_STRING=20(profile);=0A+=20=20=
if=20(memchr=20(SSDATA=20(profile),=20'\0',=20SBYTES=20(profile)))=0A+=20=
=20=20=20error=20("NUL=20in=20sandbox=20profile");=0A+=20=20char=20*err=20=
=3D=20NULL;=0A+=20=20if=20(sandbox_init_with_parameters=20(SSDATA=20=
(profile),=200,=20NULL,=20&err)=20!=3D=200)=0A+=20=20=20=20error=20=
("sandbox=20error:=20%s",=20err);=0A+=20=20return=20Qnil;=0A+}=0A+=0A=
+#endif=09/*=20DARWIN_OS=20*/=0A+=0A=20void=0A=20syms_of_sysdep=20(void)=0A=
=20{=0A=20=20=20defsubr=20(&Sget_internal_run_time);=0A+#ifdef=20=
DARWIN_OS=0A+=20=20defsubr=20(&Sdarwin_sandbox_init);=0A+#endif=0A=20}=0A=
diff=20--git=20a/test/lisp/darwin-fns-tests.el=20=
b/test/lisp/darwin-fns-tests.el=0Anew=20file=20mode=20100644=0Aindex=20=
0000000000..1e426407a1=0A---=20/dev/null=0A+++=20=
b/test/lisp/darwin-fns-tests.el=0A@@=20-0,0=20+1,90=20@@=0A+;;;=20=
darwin-fns-tests.el=20---=20tests=20for=20darwin-fns.el=20=20-*-=20=
lexical-binding:=20t=20-*-=0A+=0A+;;=20Copyright=20(C)=202021=20=20Free=20=
Software=20Foundation,=20Inc.=0A+=0A+;;=20This=20file=20is=20part=20of=20=
GNU=20Emacs.=0A+=0A+;;=20GNU=20Emacs=20is=20free=20software:=20you=20can=20=
redistribute=20it=20and/or=20modify=0A+;;=20it=20under=20the=20terms=20=
of=20the=20GNU=20General=20Public=20License=20as=20published=0A+;;=20by=20=
the=20Free=20Software=20Foundation,=20either=20version=203=20of=20the=20=
License,=0A+;;=20or=20(at=20your=20option)=20any=20later=20version.=0A+=0A=
+;;=20GNU=20Emacs=20is=20distributed=20in=20the=20hope=20that=20it=20=
will=20be=20useful,=20but=0A+;;=20WITHOUT=20ANY=20WARRANTY;=20without=20=
even=20the=20implied=20warranty=20of=0A+;;=20MERCHANTABILITY=20or=20=
FITNESS=20FOR=20A=20PARTICULAR=20PURPOSE.=20=20See=20the=20GNU=0A+;;=20=
General=20Public=20License=20for=20more=20details.=0A+=0A+;;=20You=20=
should=20have=20received=20a=20copy=20of=20the=20GNU=20General=20Public=20=
License=0A+;;=20along=20with=20GNU=20Emacs.=20=20If=20not,=20see=20=
<https://www.gnu.org/licenses/>.=0A+=0A+(require=20'ert)=0A+=0A+(defun=20=
darwin-fns-tests--run-emacs=20(expr1=20expr2)=0A+=20=20"Run=20Emacs=20in=20=
batch=20mode=20and=20evaluate=20EXPR1=20and=20EXPR2.=0A+Return=20=
(EXIT-STATUS=20.=20OUTPUT),=20where=20OUTPUT=20is=20stderr=20and=20=
stdout."=0A+=20=20(let=20((emacs=20(expand-file-name=20invocation-name=20=
invocation-directory))=0A+=20=20=20=20=20=20=20=20(process-environment=20=
nil))=0A+=20=20=20=20(with-temp-buffer=0A+=20=20=20=20=20=20(let=20((res=20=
(call-process=20emacs=20nil=20t=20nil=0A+=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"--quick"=20=
"--batch"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20(format=20"--eval=3D%S"=20expr1)=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20(format=20"--eval=3D%S"=20expr2))))=0A+=20=20=20=20=20=20=20=20=
(cons=20res=20(buffer-string))))))=0A+=0A+(ert-deftest=20=
darwin-fns-sandbox=20()=0A+=20=20(skip-unless=20(eq=20system-type=20=
'darwin))=0A+=20=20;;=20Test=20file=20reading=20and=20writing=20under=20=
various=20sandboxing=20conditions.=0A+=20=20(let*=20((some-text=20=
"abcdef")=0A+=20=20=20=20=20=20=20=20=20(new-text=20"ghijkl")=0A+=20=20=20=
=20=20=20=20=20=20(test-file=20(file-truename=20(make-temp-file=20=
"test")))=0A+=20=20=20=20=20=20=20=20=20(file-dir=20(file-name-directory=20=
test-file)))=0A+=20=20=20=20(unwind-protect=0A+=20=20=20=20=20=20=20=20=
(dolist=20(mode=20'(read=20write))=0A+=20=20=20=20=20=20=20=20=20=20=
(ert-info=20((symbol-name=20mode)=20:prefix=20"mode:=20")=0A+=20=20=20=20=
=20=20=20=20=20=20=20=20(dolist=20(sandbox=20'(allow-all=20deny-all=20=
allow-read))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20(ert-info=20=
((symbol-name=20sandbox)=20:prefix=20"sandbox:=20")=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20;;=20Prepare=20initial=20file=20contents.=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(with-temp-buffer=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(insert=20some-text)=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(write-file=20=
test-file))=0A+=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(let*=20=
((sandbox-form=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(pcase-exhaustive=20sandbox=0A+=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20('allow-all=20nil)=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20('deny-all=20'(darwin-sandbox-enter=20nil))=0A+=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20('allow-read=20=
`(darwin-sandbox-enter=20'(,file-dir)))))=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20(action-form=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(pcase-exhaustive=20=
mode=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20('read=20`(progn=20(find-file-literally=20,test-file)=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20(message=20"OK:=20%s"=20=
(buffer-string))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20('write=20`(with-temp-buffer=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20(insert=20,new-text)=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20(write-file=20,test-file)))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20(allowed=20(or=20(eq=20sandbox=20=
'allow-all)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(and=20(eq=20sandbox=20=
'allow-read)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(eq=20=
mode=20'read))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(res-out=20(darwin-fns-tests--run-emacs=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20sandbox-form=20action-form))=0A+=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20(exit-status=20(car=20res-out))=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(output=20(cdr=20res-out))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20(file-contents=0A+=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20(with-temp-buffer=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(insert-file-contents-literally=20test-file)=0A+=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(buffer-string))))=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(if=20allowed=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(should=20=
(equal=20exit-status=200))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(should-not=20(equal=20exit-status=200)))=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20(when=20(eq=20mode=20'read)=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(if=20allowed=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(should=20(equal=20output=20(format=20"OK:=20%s\n"=20some-text)))=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(should-not=20=
(string-search=20some-text=20output))))=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20(should=20(equal=20file-contents=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20(if=20(and=20(eq=20mode=20'write)=20allowed)=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20new-text=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
some-text))))))))=0A+=0A+=20=20=20=20=20=20;;=20Clean=20up.=0A+=20=20=20=20=
=20=20(ignore-errors=20(delete-file=20test-file)))))=0A+=0A+=0A+(provide=20=
'darwin-fns-tests)=0A--=20=0A2.21.1=20(Apple=20Git-122.3)=0A=0A=

--Apple-Mail=_59FECC85-2A93-4A38-B1A5-7709DA915415--

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

Received: (at 45198) by debbugs.gnu.org; 19 Apr 2021 15:42:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 19 11:42:14 2021
Received: from localhost ([127.0.0.1]:51774 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYW2P-0001Xw-Nh
	for submit <at> debbugs.gnu.org; Mon, 19 Apr 2021 11:42:14 -0400
Received: from mail1451c50.megamailservers.eu ([91.136.14.51]:42030
 helo=mail266c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1lYW2M-0001Xf-9g
 for 45198 <at> debbugs.gnu.org; Mon, 19 Apr 2021 11:42:11 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1618846923;
 bh=xBd6e47VXmRBCuDBMZ53UfFjnQpv+/r6mf8FcgoaPTE=;
 h=From:Subject:Date:In-Reply-To:Cc:To:References:From;
 b=Ue47454X4EDzE/vfa/SfAgkDR7iyY2CZgbNAp1UlB+76LcUL875xncEznGKhVjcE4
 W9rcn9GVVcTDioKZ+FaTCMXvxlwNjHk5I4Wg3kmFgriHBJm8eQFw7Rcd6FGuaVi1HC
 4T6lI0bhKA6D1w1Cjhj95C7fEDGqsksdnfcA9vwY=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-b952e353.032-75-73746f71.bbcust.telenor.se
 [83.227.82.185]) (authenticated bits=0)
 by mail266c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 13JFfwNl003772; 
 Mon, 19 Apr 2021 15:42:00 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Message-Id: <F61CF0B6-6AB0-415C-BAD4-54273D0DD476@HIDDEN>
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_59FECC85-2A93-4A38-B1A5-7709DA915415"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Date: Mon, 19 Apr 2021 17:41:58 +0200
In-Reply-To: <E967667D-698C-47FE-9E95-429C30C83907@HIDDEN>
To: Philipp <p.stephani2@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN>
 <jwvim4k6ade.fsf-monnier+emacs@HIDDEN>
 <78F41D0B-D2F6-444C-9B5C-9C50CFF2CFBD@HIDDEN>
 <E967667D-698C-47FE-9E95-429C30C83907@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A742F16.607DA4CA.0088, 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=VISjYOHX c=1 sm=1 tr=0 a=von4qPfY+hyqc0zmWf0tYQ==:117
 a=von4qPfY+hyqc0zmWf0tYQ==:17 a=M51BFTxLslgA:10 a=pGLkceISAAAA:8
 a=P_jWLAUnFZnPBouWQNAA:9 a=CjuIK1q_8ugA:10 a=2i1jUgeGfihAGWfHL1kA:9
 a=B2y7HmGcmWMA: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: 17 apr. 2021 kl. 21.42 skrev Philipp <p.stephani2@HIDDEN>:
 >> --- a/lisp/subr.el > > Should this maybe be in a platform-specific file
 such as ns-fns.el (like dos-fns.el, w32-fns.el)? Yes,
 and thank you for noticing. Now moved. 
 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: alan@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@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 (/)


--Apple-Mail=_59FECC85-2A93-4A38-B1A5-7709DA915415
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


17 apr. 2021 kl. 21.42 skrev Philipp <p.stephani2@HIDDEN>:

>> --- a/lisp/subr.el
>=20
> Should this maybe be in a platform-specific file such as ns-fns.el =
(like dos-fns.el, w32-fns.el)?

Yes, and thank you for noticing. Now moved.

> I don't think we use the "darwin-" prefix anywhere else in Emacs.  =
Maybe use a "ns-" prefix.

As Alan correctly noted this has nothing with NS to do per se, so I'm =
staying with darwin- for now.

> Also I think such internal functions commonly have an "internal" piece =
somewhere in their name, e.g. "ns-enter-sandbox-internal".

Maybe, but there is already a platform-specific prefix and a clear note =
in the doc string that it's internal. Doesn't that suffice?

>> +    (darwin-sandbox-init
>=20
> Can you also refer to the documents listed below, so that readers =
aren't wondering what this syntax means?

Thank you but that sounds unlikely since the PROFILE argument is =
described as SBPL in the function doc string.

>> +     (concat "(version 1)\n"
>=20
> Since this uses Lisp syntax, maybe use (prin1-to-string `(...))?

I'd rather not, since it's not exactly Emacs Lisp syntax. I'd like to =
avoiding conflating the two as far as possible. However...

>> +                          (format "(allow file-read* (subpath =
%S))\n" dir))
>=20
> Are you sure that the string quoting syntaxes are compatible?

It had me concerned when I wrote it too but it didn't seem possible to =
cause a false positive that way -- false negatives (access denial) at =
worst. In particular, names containing backslashes or double quotes work =
correctly.

>> +       doc: /* Enter a sandbox whose permitted access is curtailed =
by PROFILE.
>> +Already open descriptors can be used freely.
>> +PROFILE is a string in the macOS sandbox profile language,
>> +a set of rules in a Lisp-like syntax.
>=20
> I'd also refer to the Chromium document here, otherwise C-h f for this =
function won't be very useful.

I wouldn't worry -- an Emacs developer who doesn't already know it is =
more likely to duckduckgo "macos sandbox profile language" and get an =
up-to-date reference.

>> +  if (sandbox_init_with_parameters (SSDATA (profile), 0, NULL, &err) =
!=3D 0)
>=20
> If you're using SSDATA, better check that the string doesn't contain =
embedded null bytes.

There is really no way that that could ever be a problem but I added a =
check just in case.

> Also does this need to be encoded somehow?  What happens if the string =
contains non-Unicode characters like raw bytes?

Then there will be false negatives (permissions not granted) or syntax =
errors. This is just a system call wrapper; the caller is responsible =
for using reasonable arguments.

>> +    error ("sandbox error: %s", err);
>=20
> This looks like an error that clients could handle, so I'd signal a =
specific error symbol here.

That error just indicates a programming mistake. Nobody is going to =
handle it.

>> diff --git a/test/src/emacs-tests.el b/test/src/emacs-tests.el
>=20
> This should probably be in subr-tests.el since it tests a function in =
subr.el.

Right again, moved to a new file.

> I like tests that are somewhat repetitive but more decoupled and =
easier to read better than tests with factored-out assertions.

There is merit to such a style but the more important concern in this =
case is to avoid false positives and negatives, and make the tests =
robust in that regard.

It is very easy to make a mistake that renders a test meaningless, =
especially when testing a mechanism that does not alter the value of a =
computation but merely allows it to proceed or causes it to fail. The =
test has now been rewritten in a kind of oracular-combinatorial style =
which is effective in these situations. Doing so also improved coverage.

Thank you very much for your review and comments! I'd like to push the =
resulting patch but perhaps it and the rest of the sandbox development =
should go into a separate branch?


--Apple-Mail=_59FECC85-2A93-4A38-B1A5-7709DA915415
Content-Disposition: attachment;
	filename=0001-Add-macOS-sandboxing-bug-45198.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0001-Add-macOS-sandboxing-bug-45198.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=20c5006dc5260f547ff132fd42c580ea0e0fb227a7=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20=
<mattiase@HIDDEN>=0ADate:=20Sat,=2017=20Apr=202021=2020:53:39=20+0200=0A=
Subject:=20[PATCH]=20Add=20macOS=20sandboxing=20(bug#45198)=0A=0AThis=20=
is=20the=20corresponding=20low-level=20sandboxing=20facility=20=
corresponding=0Ato=20the=20recently=20added=20Seccomp=20for=20Linux.=20=20=
`darwin-sandbox-init`=20gives=0Adirect=20access=20to=20the=20system=20=
sandboxing=20call;=20`darwin-sandbox-enter`=20is=0Aa=20wrapper=20that=20=
takes=20a=20list=20of=20directories=20under=20which=20files=20can=20be=0A=
read.=20=20These=20should=20be=20considered=20internal=20mechanisms=20=
for=20now.=0A=0A*=20lisp/darwin-fns.el:=20New=20file.=0A*=20=
lisp/loadup.el:=20Load=20it.=0A*=20src/sysdep.c=20=
(Fdarwin_sandbox_init):=20New=20function.=0A*=20=
test/lisp/darwin-fns-tests.el:=20New=20file.=0A---=0A=20=
lisp/darwin-fns.el=20=20=20=20=20=20=20=20=20=20=20=20|=2040=20=
++++++++++++++++=0A=20lisp/loadup.el=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20|=20=202=20+=0A=20src/sysdep.c=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20|=2034=20+++++++++++++=0A=20=
test/lisp/darwin-fns-tests.el=20|=2090=20=
+++++++++++++++++++++++++++++++++++=0A=204=20files=20changed,=20166=20=
insertions(+)=0A=20create=20mode=20100644=20lisp/darwin-fns.el=0A=20=
create=20mode=20100644=20test/lisp/darwin-fns-tests.el=0A=0Adiff=20--git=20=
a/lisp/darwin-fns.el=20b/lisp/darwin-fns.el=0Anew=20file=20mode=20100644=0A=
index=200000000000..e45aaa0c4e=0A---=20/dev/null=0A+++=20=
b/lisp/darwin-fns.el=0A@@=20-0,0=20+1,40=20@@=0A+;;;=20darwin-fns.el=20=
---=20Darwin-specific=20functions=20=20-*-=20lexical-binding:=20t=20-*-=0A=
+=0A+;;=20Copyright=20(C)=202021=20Free=20Software=20Foundation,=20Inc.=0A=
+=0A+;;=20This=20file=20is=20part=20of=20GNU=20Emacs.=0A+=0A+;;=20GNU=20=
Emacs=20is=20free=20software:=20you=20can=20redistribute=20it=20and/or=20=
modify=0A+;;=20it=20under=20the=20terms=20of=20the=20GNU=20General=20=
Public=20License=20as=20published=20by=0A+;;=20the=20Free=20Software=20=
Foundation,=20either=20version=203=20of=20the=20License,=20or=0A+;;=20=
(at=20your=20option)=20any=20later=20version.=0A+=0A+;;=20GNU=20Emacs=20=
is=20distributed=20in=20the=20hope=20that=20it=20will=20be=20useful,=0A=
+;;=20but=20WITHOUT=20ANY=20WARRANTY;=20without=20even=20the=20implied=20=
warranty=20of=0A+;;=20MERCHANTABILITY=20or=20FITNESS=20FOR=20A=20=
PARTICULAR=20PURPOSE.=20=20See=20the=0A+;;=20GNU=20General=20Public=20=
License=20for=20more=20details.=0A+=0A+;;=20You=20should=20have=20=
received=20a=20copy=20of=20the=20GNU=20General=20Public=20License=0A+;;=20=
along=20with=20GNU=20Emacs.=20=20If=20not,=20see=20=
<https://www.gnu.org/licenses/>.=0A+=0A+;;;=20Code:=0A+=0A+(defun=20=
darwin-sandbox-enter=20(dirs)=0A+=20=20"Enter=20a=20sandbox=20only=20=
permitting=20reading=20files=20under=20DIRS.=0A+DIRS=20is=20a=20list=20=
of=20directory=20names.=20=20Most=20other=20operations=20such=20as=0A=
+writing=20files=20and=20network=20access=20are=20disallowed.=0A=
+Existing=20open=20descriptors=20can=20still=20be=20used=20freely.=0A+=0A=
+This=20is=20not=20a=20supported=20interface=20and=20is=20for=20internal=20=
use=20only."=0A+=20=20(darwin-sandbox-init=0A+=20=20=20(concat=20=
"(version=201)\n"=0A+=20=20=20=20=20=20=20=20=20=20=20"(deny=20=
default)\n"=0A+=20=20=20=20=20=20=20=20=20=20=20;;=20Emacs=20seems=20to=20=
need=20/dev/null;=20allowing=20it=20does=20no=20harm.=0A+=20=20=20=20=20=20=
=20=20=20=20=20"(allow=20file-read*=20(path=20\"/dev/null\"))\n"=0A+=20=20=
=20=20=20=20=20=20=20=20=20(mapconcat=20(lambda=20(dir)=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(format=20=
"(allow=20file-read*=20(subpath=20%S))\n"=20dir))=0A+=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20dirs=20""))))=0A+=0A=
+(provide=20'darwin-fns)=0A+=0A+;;;=20darwin-fns.el=20ends=20here=0Adiff=20=
--git=20a/lisp/loadup.el=20b/lisp/loadup.el=0Aindex=20=
d6cfcd6fc8..a6a7251d4b=20100644=0A---=20a/lisp/loadup.el=0A+++=20=
b/lisp/loadup.el=0A@@=20-324,6=20+324,8=20@@=0A=20=20=20=20=20=20=20=
(load=20"term/pc-win")=0A=20=20=20=20=20=20=20(load=20"ls-lisp")=0A=20=20=
=20=20=20=20=20(load=20"disp-table")))=20;=20needed=20to=20setup=20=
ibm-pc=20char=20set,=20see=20internal.el=0A+(if=20(eq=20system-type=20=
'darwin)=0A+=20=20=20=20(load=20"darwin-fns"))=0A=20(if=20(featurep=20=
'ns)=0A=20=20=20=20=20(progn=0A=20=20=20=20=20=20=20(load=20=
"term/common-win")=0Adiff=20--git=20a/src/sysdep.c=20b/src/sysdep.c=0A=
index=20d940acc4e0..4ea1f0050a=20100644=0A---=20a/src/sysdep.c=0A+++=20=
b/src/sysdep.c=0A@@=20-4286,8=20+4286,42=20@@=20str_collate=20=
(Lisp_Object=20s1,=20Lisp_Object=20s2,=0A=20}=0A=20#endif=09/*=20=
WINDOWSNT=20*/=0A=20=0A+#ifdef=20DARWIN_OS=0A+=0A+/*=20This=20function=20=
prototype=20is=20not=20in=20the=20platform=20header=20files.=0A+=20=20=20=
See=20=
https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0=
.pdf=0A+=20=20=20and=20=
https://chromium.googlesource.com/chromium/src/+/master/sandbox/mac/seatbe=
lt_sandbox_design.md=20*/=0A+int=20sandbox_init_with_parameters(const=20=
char=20*profile,=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20uint64_t=20flags,=0A+=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20const=20char=20*const=20parameters[],=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20char=20**errorbuf);=0A+=0A+DEFUN=20("darwin-sandbox-init",=20=
Fdarwin_sandbox_init,=20Sdarwin_sandbox_init,=0A+=20=20=20=20=20=20=201,=20=
1,=200,=0A+=20=20=20=20=20=20=20doc:=20/*=20Enter=20a=20sandbox=20whose=20=
permitted=20access=20is=20curtailed=20by=20PROFILE.=0A+Already=20open=20=
descriptors=20can=20be=20used=20freely.=0A+PROFILE=20is=20a=20string=20=
in=20the=20macOS=20sandbox=20profile=20language,=0A+a=20set=20of=20rules=20=
in=20a=20Lisp-like=20syntax.=0A+=0A+This=20is=20not=20a=20supported=20=
interface=20and=20is=20for=20internal=20use=20only.=20*/)=0A+=20=20=
(Lisp_Object=20profile)=0A+{=0A+=20=20CHECK_STRING=20(profile);=0A+=20=20=
if=20(memchr=20(SSDATA=20(profile),=20'\0',=20SBYTES=20(profile)))=0A+=20=
=20=20=20error=20("NUL=20in=20sandbox=20profile");=0A+=20=20char=20*err=20=
=3D=20NULL;=0A+=20=20if=20(sandbox_init_with_parameters=20(SSDATA=20=
(profile),=200,=20NULL,=20&err)=20!=3D=200)=0A+=20=20=20=20error=20=
("sandbox=20error:=20%s",=20err);=0A+=20=20return=20Qnil;=0A+}=0A+=0A=
+#endif=09/*=20DARWIN_OS=20*/=0A+=0A=20void=0A=20syms_of_sysdep=20(void)=0A=
=20{=0A=20=20=20defsubr=20(&Sget_internal_run_time);=0A+#ifdef=20=
DARWIN_OS=0A+=20=20defsubr=20(&Sdarwin_sandbox_init);=0A+#endif=0A=20}=0A=
diff=20--git=20a/test/lisp/darwin-fns-tests.el=20=
b/test/lisp/darwin-fns-tests.el=0Anew=20file=20mode=20100644=0Aindex=20=
0000000000..1e426407a1=0A---=20/dev/null=0A+++=20=
b/test/lisp/darwin-fns-tests.el=0A@@=20-0,0=20+1,90=20@@=0A+;;;=20=
darwin-fns-tests.el=20---=20tests=20for=20darwin-fns.el=20=20-*-=20=
lexical-binding:=20t=20-*-=0A+=0A+;;=20Copyright=20(C)=202021=20=20Free=20=
Software=20Foundation,=20Inc.=0A+=0A+;;=20This=20file=20is=20part=20of=20=
GNU=20Emacs.=0A+=0A+;;=20GNU=20Emacs=20is=20free=20software:=20you=20can=20=
redistribute=20it=20and/or=20modify=0A+;;=20it=20under=20the=20terms=20=
of=20the=20GNU=20General=20Public=20License=20as=20published=0A+;;=20by=20=
the=20Free=20Software=20Foundation,=20either=20version=203=20of=20the=20=
License,=0A+;;=20or=20(at=20your=20option)=20any=20later=20version.=0A+=0A=
+;;=20GNU=20Emacs=20is=20distributed=20in=20the=20hope=20that=20it=20=
will=20be=20useful,=20but=0A+;;=20WITHOUT=20ANY=20WARRANTY;=20without=20=
even=20the=20implied=20warranty=20of=0A+;;=20MERCHANTABILITY=20or=20=
FITNESS=20FOR=20A=20PARTICULAR=20PURPOSE.=20=20See=20the=20GNU=0A+;;=20=
General=20Public=20License=20for=20more=20details.=0A+=0A+;;=20You=20=
should=20have=20received=20a=20copy=20of=20the=20GNU=20General=20Public=20=
License=0A+;;=20along=20with=20GNU=20Emacs.=20=20If=20not,=20see=20=
<https://www.gnu.org/licenses/>.=0A+=0A+(require=20'ert)=0A+=0A+(defun=20=
darwin-fns-tests--run-emacs=20(expr1=20expr2)=0A+=20=20"Run=20Emacs=20in=20=
batch=20mode=20and=20evaluate=20EXPR1=20and=20EXPR2.=0A+Return=20=
(EXIT-STATUS=20.=20OUTPUT),=20where=20OUTPUT=20is=20stderr=20and=20=
stdout."=0A+=20=20(let=20((emacs=20(expand-file-name=20invocation-name=20=
invocation-directory))=0A+=20=20=20=20=20=20=20=20(process-environment=20=
nil))=0A+=20=20=20=20(with-temp-buffer=0A+=20=20=20=20=20=20(let=20((res=20=
(call-process=20emacs=20nil=20t=20nil=0A+=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"--quick"=20=
"--batch"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20(format=20"--eval=3D%S"=20expr1)=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20(format=20"--eval=3D%S"=20expr2))))=0A+=20=20=20=20=20=20=20=20=
(cons=20res=20(buffer-string))))))=0A+=0A+(ert-deftest=20=
darwin-fns-sandbox=20()=0A+=20=20(skip-unless=20(eq=20system-type=20=
'darwin))=0A+=20=20;;=20Test=20file=20reading=20and=20writing=20under=20=
various=20sandboxing=20conditions.=0A+=20=20(let*=20((some-text=20=
"abcdef")=0A+=20=20=20=20=20=20=20=20=20(new-text=20"ghijkl")=0A+=20=20=20=
=20=20=20=20=20=20(test-file=20(file-truename=20(make-temp-file=20=
"test")))=0A+=20=20=20=20=20=20=20=20=20(file-dir=20(file-name-directory=20=
test-file)))=0A+=20=20=20=20(unwind-protect=0A+=20=20=20=20=20=20=20=20=
(dolist=20(mode=20'(read=20write))=0A+=20=20=20=20=20=20=20=20=20=20=
(ert-info=20((symbol-name=20mode)=20:prefix=20"mode:=20")=0A+=20=20=20=20=
=20=20=20=20=20=20=20=20(dolist=20(sandbox=20'(allow-all=20deny-all=20=
allow-read))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20(ert-info=20=
((symbol-name=20sandbox)=20:prefix=20"sandbox:=20")=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20;;=20Prepare=20initial=20file=20contents.=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(with-temp-buffer=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(insert=20some-text)=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(write-file=20=
test-file))=0A+=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(let*=20=
((sandbox-form=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(pcase-exhaustive=20sandbox=0A+=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20('allow-all=20nil)=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20('deny-all=20'(darwin-sandbox-enter=20nil))=0A+=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20('allow-read=20=
`(darwin-sandbox-enter=20'(,file-dir)))))=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20(action-form=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(pcase-exhaustive=20=
mode=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20('read=20`(progn=20(find-file-literally=20,test-file)=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20(message=20"OK:=20%s"=20=
(buffer-string))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20('write=20`(with-temp-buffer=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20(insert=20,new-text)=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20(write-file=20,test-file)))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20(allowed=20(or=20(eq=20sandbox=20=
'allow-all)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(and=20(eq=20sandbox=20=
'allow-read)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(eq=20=
mode=20'read))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(res-out=20(darwin-fns-tests--run-emacs=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20sandbox-form=20action-form))=0A+=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20(exit-status=20(car=20res-out))=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(output=20(cdr=20res-out))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20(file-contents=0A+=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20(with-temp-buffer=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(insert-file-contents-literally=20test-file)=0A+=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(buffer-string))))=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(if=20allowed=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(should=20=
(equal=20exit-status=200))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20(should-not=20(equal=20exit-status=200)))=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20(when=20(eq=20mode=20'read)=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(if=20allowed=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(should=20(equal=20output=20(format=20"OK:=20%s\n"=20some-text)))=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(should-not=20=
(string-search=20some-text=20output))))=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20(should=20(equal=20file-contents=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20(if=20(and=20(eq=20mode=20'write)=20allowed)=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20new-text=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
some-text))))))))=0A+=0A+=20=20=20=20=20=20;;=20Clean=20up.=0A+=20=20=20=20=
=20=20(ignore-errors=20(delete-file=20test-file)))))=0A+=0A+=0A+(provide=20=
'darwin-fns-tests)=0A--=20=0A2.21.1=20(Apple=20Git-122.3)=0A=0A=

--Apple-Mail=_59FECC85-2A93-4A38-B1A5-7709DA915415--

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

Received: (at 45198) by debbugs.gnu.org; 18 Apr 2021 14:25:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 10:25:57 2021
Received: from localhost ([127.0.0.1]:47374 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY8N2-00020m-RT
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 10:25:57 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34406)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lY8N1-00020Y-Mk
 for 45198 <at> debbugs.gnu.org; Sun, 18 Apr 2021 10:25:56 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 22BBA80BA3;
 Sun, 18 Apr 2021 10:25:50 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CAC5C8075E;
 Sun, 18 Apr 2021 10:25:48 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618755948;
 bh=FawMmGa/6Ask3xFRX3NMZigvuXbzBHEflSCpWuBNHIM=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=fhe4hgitkXBWy8so9kkjXMouUMdjbj8TJIMloGmlY4upORqS1TKCihbXcMTrB8ciK
 ELeyC1f1pJeDuY+aTtMJ1g1Kyta7st9y1COFCscR5e6vL+k/o1sAkSAAm9F5MGSvTO
 bR+xKiO9rVi+GIA7tc4UQ/KukLou0bQyLXQKMrSChhg3ld9+qHtNVyqfxqPgidyLsE
 xU/ftdTpjI0XVKYHhmW0ABoREkzH8ZLLYKZ39Ji99vJHEGDebt8pFtNIuV7tuvuc3Y
 2sWorKhklqdNXfv5T1AcNIT4EouHMVKsTC2Aa1WLTV+8GrPyp4JRIAsWnQ67RbfnP3
 L4rznGBv9lXYA==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7A7D712022C;
 Sun, 18 Apr 2021 10:25:48 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwvlf9f3c7i.fsf-monnier+emacs@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <jwva6pwalxc.fsf-monnier+emacs@HIDDEN> <83o8ecvnok.fsf@HIDDEN>
 <jwv5z0k7qeg.fsf-monnier+emacs@HIDDEN> <83lf9gvktv.fsf@HIDDEN>
 <jwv7dl069cy.fsf-monnier+emacs@HIDDEN> <83im4kvi4e.fsf@HIDDEN>
 <jwv1rb864yg.fsf-monnier+emacs@HIDDEN> <83blacun30.fsf@HIDDEN>
Date: Sun, 18 Apr 2021 10:25:47 -0400
In-Reply-To: <83blacun30.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 18 Apr
 2021 09:24:35 +0300")
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.053 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: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 p.stephani2@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 (---)

>> The whole point of the sandboxing exercise is so as to be able to have
>> flymake-mode in the hook without exposing yourself to
>> these vulnerabilities.
>
> So we are going to introduce all this non-trivial machinery into Emacs
> just to solve the Flymake use case?  Is that reasonable from the
> project management POV, in your eyes?

To the extent that this machinery will only be used by those rare places
that need it (e.g. flymake), yes, as long as the low-level interface
(e.g. the code that added the support for the `--seccomp` argument) is
simple enough.

BTW, in the context of GNU/Linux, an alternative to `--seccomp` is to
require the `bwrap` tool (that's what I use in the `elpa-admin.el`
scripts to run makefile rules from ELPA packages).


        Stefan

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

Received: (at 45198) by debbugs.gnu.org; 18 Apr 2021 09:23:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 05:23:49 2021
Received: from localhost ([127.0.0.1]:45304 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY3ef-0002Gy-Dd
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 05:23:49 -0400
Received: from eggs.gnu.org ([209.51.188.92]:52340)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lY3ee-0002Gm-DG
 for 45198 <at> debbugs.gnu.org; Sun, 18 Apr 2021 05:23:48 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:48517)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lY3eY-00051t-2T; Sun, 18 Apr 2021 05:23:42 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2379
 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 1lY3eV-0001GV-Ec; Sun, 18 Apr 2021 05:23:40 -0400
Date: Sun, 18 Apr 2021 12:23:20 +0300
Message-Id: <83tuo4t08n.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <CAArVCkThkE1iZwxOL78pJAzX2Vr8KxS9jn5dq1h_1DfS9+4LMQ@HIDDEN>
 (message from Philipp Stephani on Sun, 18 Apr 2021 11:11:28 +0200)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <83v98kvr7y.fsf@HIDDEN> <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <83tuo4vqet.fsf@HIDDEN>
 <CAArVCkQq5Zrdk31wdoDmTSqbEc+aPHdLy8w9ZuZmzQ2t83NSjw@HIDDEN>
 <83r1j8vpku.fsf@HIDDEN>
 <CAArVCkT-xh4oJ5a1Bgctn62DMNK5_xw5+mg1jRZchV1Pcrq0bQ@HIDDEN>
 <83fszovhox.fsf@HIDDEN> <8491CEA9-E230-48E4-9AB3-71DF0B4D8A2B@HIDDEN>
 <83czusun95.fsf@HIDDEN>
 <CAArVCkThkE1iZwxOL78pJAzX2Vr8KxS9jn5dq1h_1DfS9+4LMQ@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org,
 stefankangas@HIDDEN, joaotavora@HIDDEN, 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.7 (-)

> From: Philipp Stephani <p.stephani2@HIDDEN>
> Date: Sun, 18 Apr 2021 11:11:28 +0200
> Cc: Mattias Engdegård <mattiase@HIDDEN>, 
> 	João Távora <joaotavora@HIDDEN>, 
> 	45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>, 
> 	Stefan Monnier <monnier@HIDDEN>, Alan Third <alan@HIDDEN>
> 
> > > >  And what about users who make local changes
> > > > in their Emacs?
> > >
> > > They can provide their own Seccomp policies or modify the ones included in Emacs.
> >
> > What does providing a policy entail? can you describe the procedure of
> > tailoring a policy to changes in the Emacs code?
> 
> 1. Run the Emacs sandbox with the code you want to run.
> 2. Emacs will crash with SIGSYS if it hits a forbidden/unknown
> syscall. Ensure that this generates a coredump.
> 3. Check the backtrace for the coredump (e.g. coredumpctl debug)
> and/or the Seccomp audit logs (ausearch) for the syscall that
> triggered the signal.
> 4. Add a rule for the syscall and its arguments to the BPF generation
> program, e.g. lib-src/seccom-filter.c.
> 5. Regenerate the BPF rule file.

Sounds complicated, and requires non-trivial low-level knowledge and
tools.

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

Received: (at 45198) by debbugs.gnu.org; 18 Apr 2021 09:11:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 05:11:48 2021
Received: from localhost ([127.0.0.1]:45298 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY3T2-0001zK-8H
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 05:11:48 -0400
Received: from mail-oi1-f174.google.com ([209.85.167.174]:36558)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lY3T0-0001z6-1I
 for 45198 <at> debbugs.gnu.org; Sun, 18 Apr 2021 05:11:46 -0400
Received: by mail-oi1-f174.google.com with SMTP id v6so4742036oiv.3
 for <45198 <at> debbugs.gnu.org>; Sun, 18 Apr 2021 02:11:46 -0700 (PDT)
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=ynZNtmo/+mbeYd6ZY4OnnKdOZkr2/8Ltl47nkRjw7jk=;
 b=VpipkC/+MFbYFrnn8f6KH9lRrLCAEjN9swrXmRNOmYoFuTIwaacq4jfy2L5Efwjt1V
 PuBF67gajI7rJMH/QhopQyJyF47RPW+tkr21yXm9D5UwERjJR+6mlvIXjoDrEeoHsxzV
 7IvkhqWZAaqF/yHJYJWP2xnCedMwi1hMRPOUEUGVBzY3XHBJd4we8ghSqZFSJJXKJIWX
 yDvSWdufeRZ8NAIvrsfvTaVOBqPiNkf5nPyeHUdYEqsmait2XhwpqXkhRAAFjXdnzLwt
 LpgfcWO+esV3/llRJc26RMda3ZPmw/t/OTQWzTVg7K9aGq1GztwYUTYZoFXxycRCJtaS
 d9Lg==
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=ynZNtmo/+mbeYd6ZY4OnnKdOZkr2/8Ltl47nkRjw7jk=;
 b=L/CujC9+BCeFQQZNXiM7/rM0rfNLXcIUwFgr0BLWbQrGFbOIesHEB7VYx2zYJ+LBv2
 fdOkZj3XPPaxNVeGTx31nFPoL6e9IJ+yyQQA6WzWPs5IAop0lXr1SaB0Kfu7Y++3UZe7
 cgTT7HmcU7AyoVursuAVVZRFg1+B2+AGQiBVXC9GO1h+SqY31pZmPXP7AFk/L/idCeQa
 eAjy/Zdl196ms69Jx8H8JFsvrNccTOiLdV3pctDe5/6EOGZq1WoKuPaXftnXkOJQNtEk
 7bBfZf/IaNXc3jG8rrRXN91ngQ8OvH1N6ZJd1MMeD/fz8yoTOf7kQSUHI9c9l+9iwFxr
 uWrw==
X-Gm-Message-State: AOAM531qoFK8dLVgtWfihhpGNtiougfy9zyibgPotMDOnStLfmSRtKN/
 xGjMKBtO3EAYPAKG8Y2RjOmFI/QxT8ax9MCBKDY=
X-Google-Smtp-Source: ABdhPJz5x2blbiceWpvrHxkY773iyVVKLk88uxgd+6seLml/ubOyE7Z0PphUYxKq4nMhAQ9uVyC7ilC0QbDLlqMdiLI=
X-Received: by 2002:aca:1814:: with SMTP id h20mr12139915oih.150.1618737100372; 
 Sun, 18 Apr 2021 02:11:40 -0700 (PDT)
MIME-Version: 1.0
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <83v98kvr7y.fsf@HIDDEN> <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <83tuo4vqet.fsf@HIDDEN>
 <CAArVCkQq5Zrdk31wdoDmTSqbEc+aPHdLy8w9ZuZmzQ2t83NSjw@HIDDEN>
 <83r1j8vpku.fsf@HIDDEN>
 <CAArVCkT-xh4oJ5a1Bgctn62DMNK5_xw5+mg1jRZchV1Pcrq0bQ@HIDDEN>
 <83fszovhox.fsf@HIDDEN> <8491CEA9-E230-48E4-9AB3-71DF0B4D8A2B@HIDDEN>
 <83czusun95.fsf@HIDDEN>
In-Reply-To: <83czusun95.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sun, 18 Apr 2021 11:11:28 +0200
Message-ID: <CAArVCkThkE1iZwxOL78pJAzX2Vr8KxS9jn5dq1h_1DfS9+4LMQ@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: 1.2 (+)
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:  Am So., 18. Apr. 2021 um 08:21 Uhr schrieb Eli Zaretskii :
    > > > From: Philipp > > Date: Sat, 17 Apr 2021 21:52:59 +0200 > > Cc: Mattias
    Engdegård , > > João Távora , > > 45198 <at> debbugs.gnu.org [...] 
 
 Content analysis details:   (1.2 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
                             in digit (p.stephani2[at]gmail.com)
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (p.stephani2[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.167.174 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.167.174 listed in wl.mailspike.net]
  1.0 FREEMAIL_REPLY         From and body contain different freemails
X-Debbugs-Envelope-To: 45198
Cc: Alan Third <alan@HIDDEN>,
 =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@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: -0.8 (/)

Am So., 18. Apr. 2021 um 08:21 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
>
> > From: Philipp <p.stephani2@HIDDEN>
> > Date: Sat, 17 Apr 2021 21:52:59 +0200
> > Cc: Mattias Engdeg=C3=A5rd <mattiase@HIDDEN>,
> >  Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>,
> >  45198 <at> debbugs.gnu.org,
> >  stefankangas@HIDDEN,
> >  monnier@HIDDEN,
> >  alan@HIDDEN
> >
> > > So you are going to suggest that we rely on some auditing of the
> > > syscalls Emacs uses now to decide which ones to filter and which not?
> >
> > I don't mean that we should wade through all potential syscalls that Em=
acs could make.  Typically you can come up with such a Seccomp policy itera=
tively: run Seccomp in advisory mode (i.e. only log syscalls), then allow t=
he syscalls that are both necessary and harmless in the policy.
>
> Emacs can be invoked to do many different things, and will
> correspondingly present very different profiles of syscalls.  Is the
> procedure you envision practical, let alone seamless, given that it
> will have to become part of the maintenance and the release process?

Yes. There aren't that many syscalls to begin with, and Emacs uses
only a small subset of them. New Emacs or libc versions occasionally
introduce new syscalls, but finding and allowing them tends to be not
that big of a deal.

> > >  And what about users who make local changes
> > > in their Emacs?
> >
> > They can provide their own Seccomp policies or modify the ones included=
 in Emacs.
>
> What does providing a policy entail? can you describe the procedure of
> tailoring a policy to changes in the Emacs code?

1. Run the Emacs sandbox with the code you want to run.
2. Emacs will crash with SIGSYS if it hits a forbidden/unknown
syscall. Ensure that this generates a coredump.
3. Check the backtrace for the coredump (e.g. coredumpctl debug)
and/or the Seccomp audit logs (ausearch) for the syscall that
triggered the signal.
4. Add a rule for the syscall and its arguments to the BPF generation
program, e.g. lib-src/seccom-filter.c.
5. Regenerate the BPF rule file.

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

Received: (at 45198) by debbugs.gnu.org; 18 Apr 2021 06:25:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 02:25:13 2021
Received: from localhost ([127.0.0.1]:45130 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY0rk-0004F2-M2
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 02:25:12 -0400
Received: from eggs.gnu.org ([209.51.188.92]:34446)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lY0rf-0004E1-Dx
 for 45198 <at> debbugs.gnu.org; Sun, 18 Apr 2021 02:25:06 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:47223)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lY0rX-00084g-Tu; Sun, 18 Apr 2021 02:24:56 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3319
 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 1lY0rX-0003vz-B5; Sun, 18 Apr 2021 02:24:55 -0400
Date: Sun, 18 Apr 2021 09:24:35 +0300
Message-Id: <83blacun30.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwv1rb864yg.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 17 Apr 2021 16:26:25 -0400)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <jwva6pwalxc.fsf-monnier+emacs@HIDDEN> <83o8ecvnok.fsf@HIDDEN>
 <jwv5z0k7qeg.fsf-monnier+emacs@HIDDEN> <83lf9gvktv.fsf@HIDDEN>
 <jwv7dl069cy.fsf-monnier+emacs@HIDDEN> <83im4kvi4e.fsf@HIDDEN>
 <jwv1rb864yg.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 p.stephani2@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: -1.7 (-)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: mattiase@HIDDEN,  joaotavora@HIDDEN,  p.stephani2@HIDDEN,
>   stefan@HIDDEN,  45198 <at> debbugs.gnu.org,  alan@HIDDEN
> Date: Sat, 17 Apr 2021 16:26:25 -0400
> 
> > If you are implying that one does something conscious and deliberate
> > before byte-compiling a file,
> 
> Have you ever byte-compiled a random ELisp file sent to you from some
> unknown email address without looking at it first?

No, but I also don't use Flymake and never install packages via
package.el.

IOW, my own workflows are not very relevant to the issues at hand, and
neither are yours.  What matters is what others do.

> The whole point of the sandboxing exercise is so as to be able to have
> flymake-mode in the hook without exposing yourself to
> these vulnerabilities.

So we are going to introduce all this non-trivial machinery into Emacs
just to solve the Flymake use case?  Is that reasonable from the
project management POV, in your eyes?

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

Received: (at 45198) by debbugs.gnu.org; 18 Apr 2021 06:21:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 02:21:25 2021
Received: from localhost ([127.0.0.1]:45121 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY0o8-00048a-PD
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 02:21:25 -0400
Received: from eggs.gnu.org ([209.51.188.92]:34096)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lY0o6-00048J-Rz
 for 45198 <at> debbugs.gnu.org; Sun, 18 Apr 2021 02:21:23 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:47211)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lY0nz-0006EA-Hd; Sun, 18 Apr 2021 02:21:15 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3088
 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 1lY0nz-0003jO-0J; Sun, 18 Apr 2021 02:21:15 -0400
Date: Sun, 18 Apr 2021 09:20:54 +0300
Message-Id: <83czusun95.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp <p.stephani2@HIDDEN>
In-Reply-To: <8491CEA9-E230-48E4-9AB3-71DF0B4D8A2B@HIDDEN> (message from
 Philipp on Sat, 17 Apr 2021 21:52:59 +0200)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN> <83tuo4vqet.fsf@HIDDEN>
 <CAArVCkQq5Zrdk31wdoDmTSqbEc+aPHdLy8w9ZuZmzQ2t83NSjw@HIDDEN>
 <83r1j8vpku.fsf@HIDDEN>
 <CAArVCkT-xh4oJ5a1Bgctn62DMNK5_xw5+mg1jRZchV1Pcrq0bQ@HIDDEN>
 <83fszovhox.fsf@HIDDEN> <8491CEA9-E230-48E4-9AB3-71DF0B4D8A2B@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org,
 stefankangas@HIDDEN, joaotavora@HIDDEN, 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.7 (-)

> From: Philipp <p.stephani2@HIDDEN>
> Date: Sat, 17 Apr 2021 21:52:59 +0200
> Cc: Mattias Engdegård <mattiase@HIDDEN>,
>  João Távora <joaotavora@HIDDEN>,
>  45198 <at> debbugs.gnu.org,
>  stefankangas@HIDDEN,
>  monnier@HIDDEN,
>  alan@HIDDEN
> 
> > So you are going to suggest that we rely on some auditing of the
> > syscalls Emacs uses now to decide which ones to filter and which not?
> 
> I don't mean that we should wade through all potential syscalls that Emacs could make.  Typically you can come up with such a Seccomp policy iteratively: run Seccomp in advisory mode (i.e. only log syscalls), then allow the syscalls that are both necessary and harmless in the policy.

Emacs can be invoked to do many different things, and will
correspondingly present very different profiles of syscalls.  Is the
procedure you envision practical, let alone seamless, given that it
will have to become part of the maintenance and the release process?

> > If so, how will this work in the future, when Emacs might decide to
> > issue some additional syscalls? who and how will remember to update
> > the filter definitions?
> 
> There are unit tests that ensure that the behavior we expect works.

Unit tests are a far cry from what Emacs does in real-life usage, so I
very much doubt that unit tests will suffice in this case.

> >  And what about users who make local changes
> > in their Emacs?
> 
> They can provide their own Seccomp policies or modify the ones included in Emacs.

What does providing a policy entail? can you describe the procedure of
tailoring a policy to changes in the Emacs code?

> >> At least initially we should only care about batch mode, though -
> >> nothing prevents interactive mode in a sandbox in principle, but batch
> >> mode is much easier to deal with, and suffices for the Flymake use
> >> case.
> > 
> > I understand why batch mode might be easier to deal with, but I'm not
> > sure we should care more about it just because it's easier.
> 
> We care about it in the scope of the feature being discussed (Flymake) because Flymake runs Emacs in batch mode anyway.

So we will make running Flymake safe, but what about all the other use
cases where similar dangers exist?  Flymake is just a tiny fraction of
what Emacs does, so it sounds strange, to say the least, to work on
solution for that use case alone, when it is clear from the get-go
that many other use cases aren't covered.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 20:26:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 16:26:35 2021
Received: from localhost ([127.0.0.1]:44756 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXrWV-0002EY-G3
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 16:26:35 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26286)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lXrWT-0002EI-KX
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 16:26:33 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 284EB100222;
 Sat, 17 Apr 2021 16:26:28 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 91F181000C9;
 Sat, 17 Apr 2021 16:26:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618691186;
 bh=E+dHsDtUmvYPcuMBofbdggfjKYzvw7+GEk/UjyIZDXU=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=U/7wth+N1XcBvnRaMqqSOuS1iEDdlrdPmr6sZT8k7b+Xs71r8f53/CnD6jD46kqLk
 ZK4z5yDdKbR8BEa3DRnQi3tmk0oxbTj0p2LQ2ByxMOYBcUs74Yo25hDVQfcwg7uheX
 ceOJ+pelv6YYf3X7nqctwZEI762bxRzvjgNZYBcyq2ZWq5nt+fUpqrur2KVZmNo0dY
 xOzVWNPVY4uWhdTPDsQoLMHoZGKRGYVdxYfq6skcN6VZ19Wbag7XauemKKfPUk8qU1
 D6+W4t3yiMFolxjHWtNMaQ0wZAhQ/FqgQLRoZfOR6IF/Uw8e7lgJGlSW9tzTWb6pbj
 pyAID25OXALZQ==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 403691202AD;
 Sat, 17 Apr 2021 16:26:26 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwv1rb864yg.fsf-monnier+emacs@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <jwva6pwalxc.fsf-monnier+emacs@HIDDEN> <83o8ecvnok.fsf@HIDDEN>
 <jwv5z0k7qeg.fsf-monnier+emacs@HIDDEN> <83lf9gvktv.fsf@HIDDEN>
 <jwv7dl069cy.fsf-monnier+emacs@HIDDEN> <83im4kvi4e.fsf@HIDDEN>
Date: Sat, 17 Apr 2021 16:26:25 -0400
In-Reply-To: <83im4kvi4e.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 17 Apr
 2021 22:14:09 +0300")
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.021 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: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 p.stephani2@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 (---)

>> The normal way to enable flymake is something like
>>
>>     (add-hook 'emacs-lisp-mode #'flymake-mode)
>>
>> so the file gets compiled just because you're looking at it.
>> That's quite different from an explicit request from the user to compile
>> a file.
>
> It is?  Sorry, I don't see the difference, not a significant one.

It make `C-x C-f` a tool to run arbitrary code (since the file may end
with something apparently harmless like `.txt` but may actually use
`emacs-lisp-mode`).

> If you are implying that one does something conscious and deliberate
> before byte-compiling a file,

Have you ever byte-compiled a random ELisp file sent to you from some
unknown email address without looking at it first?

Have you ever viewed with Emacs a file sent from some unknown
email address?

For me the answers are "no, never" and "yes, many times".
Enabling flymake mode as above currently blurs the difference between
those two cases in terms of risks.

> then one could also remove Flymake from the hook while at that.

The whole point of the sandboxing exercise is so as to be able to have
flymake-mode in the hook without exposing yourself to
these vulnerabilities.


        Stefan

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:58:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 15:58:13 2021
Received: from localhost ([127.0.0.1]:44712 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXr53-0001Wt-AF
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:58:13 -0400
Received: from outbound.soverin.net ([116.202.65.218]:54177)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alan@HIDDEN>) id 1lXr51-0001Wd-8b
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:58:12 -0400
Received: from smtp.soverin.net (unknown [10.10.3.28])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
 (No client certificate requested)
 by outbound.soverin.net (Postfix) with ESMTPS id 6076F601B8;
 Sat, 17 Apr 2021 19:58:03 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by
 soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin;
 t=1618689481; bh=0mIiFn2oP9ISihYPjw8gvV3w48yPKz6mYVpyGZ6eVE8=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=RvXLmMEVWXgfFQK9R530MXHg3LNDTYVW4k8mmNB7V6cMfB5ppzQQMdMXgad08xs75
 dVZX3NiIImDcg8ik0V7GjlAlue27N/2zbWsnHMY3DyEg55VXvs7dx5+xSi5VUpSnH+
 d1UEzayHlDUX9pZKLlqoq7PSPmEhjuhlflmIYYaHlkD+omBRFgEj9Paq7NIiMFLmes
 5//AfFMO9ZfvVz20i4gerge5UNwD65Iymo2UnlqZGkvz7KM23PsSRMe4IcrLAmRAOs
 pu0XYX16gWjRiTjh3lplaLBDAvz8IAXxqktRNl375IPzIou5zCl0lAlR5sp85zXEV2
 UJwM5Mm+ezzsQ==
Received: by breton.holly.idiocy.org (Postfix, from userid 501)
 id 72474202BD1872; Sat, 17 Apr 2021 20:57:57 +0100 (BST)
Date: Sat, 17 Apr 2021 20:57:57 +0100
From: Alan Third <alan@HIDDEN>
To: Philipp <p.stephani2@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <YHs9xSgEtFgwJ1LR@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
 Philipp <p.stephani2@HIDDEN>,
 Mattias =?iso-8859-1?Q?Engdeg=E5rd?= <mattiase@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>,
 Eli Zaretskii <eliz@HIDDEN>,
 =?iso-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN>,
 45198 <at> debbugs.gnu.org, stefan@HIDDEN
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN>
 <jwvim4k6ade.fsf-monnier+emacs@HIDDEN>
 <78F41D0B-D2F6-444C-9B5C-9C50CFF2CFBD@HIDDEN>
 <E967667D-698C-47FE-9E95-429C30C83907@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E967667D-698C-47FE-9E95-429C30C83907@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= <mattiase@HIDDEN>,
 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 =?iso-8859-1?Q?Jo=E3o_T=E1vora?= <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: -1.7 (-)

On Sat, Apr 17, 2021 at 09:42:31PM +0200, Philipp wrote:
> > diff --git a/lisp/subr.el b/lisp/subr.el
> > index c2be26a15f..196512c0c6 100644
> > --- a/lisp/subr.el
> > +++ b/lisp/subr.el
> 
> Should this maybe be in a platform-specific file such as ns-fns.el (like dos-fns.el, w32-fns.el)?

> > @@ -6262,4 +6262,22 @@ internal--format-docstring-line
> >  This is intended for internal use only."
> >    (internal--fill-string-single-line (apply #'format string objects)))
> >  
> > +(when (eq system-type 'darwin)
> > +  (defun darwin-sandbox-enter (dirs)
> 
> I don't think we use the "darwin-" prefix anywhere else in Emacs.
> Maybe use a "ns-" prefix. Also I think such internal functions
> commonly have an "internal" piece somewhere in their name, e.g.
> "ns-enter-sandbox-internal".

I'm coming to this late, so I may be misunderstanding what this is,
but as far as I can tell it has nothing to do with Cocoa or GNUstep,
so I would suggest not using the ns- prefix.

If you're running, say, terminal Emacs on a Darwin system, ns-fns.el
is not called.

NS =/= Darwin.

-- 
Alan Third

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:53:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 15:53:09 2021
Received: from localhost ([127.0.0.1]:44704 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXr09-0001Pb-Aw
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:53:09 -0400
Received: from mail-ed1-f50.google.com ([209.85.208.50]:39731)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lXr07-0001PB-4c
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:53:07 -0400
Received: by mail-ed1-f50.google.com with SMTP id g17so35454082edm.6
 for <45198 <at> debbugs.gnu.org>; Sat, 17 Apr 2021 12:53:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=ehCvAHzswN4dSh+lj3ESMjjurqy/kyAOScBpDQB2UIs=;
 b=mCF5EoLL20Y7HT/NIHGLdwGJmWmeugWc63fMIIqWsf3kJ3h22TMVDEOabE76Dk2uBp
 X0t1EhYtK7siPULAS91K/IoOnv9ewgF4rWwgALN1cCURBF9YGFJa/8bg5e5a6PoADQ04
 ccLw958NzfsoWWhSaccztkWYZZTun9rS4pklFr+pTbFEhE8MoNE9Fpju8VT4vKGtYIQK
 Fu1gOUp6ImRPP6D1341VMCXTQfB2GTWnnkWvjT+f0ueNVDnWHo8C5dECZXkXqD9ixqNk
 h+qJb2/VtYNXIUBOE0pKLXmhgv1dp0EPPUXonwTinVPJBpQK9CY5wOueQFLdXAoDxGZ9
 GU3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=ehCvAHzswN4dSh+lj3ESMjjurqy/kyAOScBpDQB2UIs=;
 b=ct2ztXBshI87yhmcBu5n1F1+vjc1ChYeJm741uuDJym/Ds6V0aIHfosEw2i/fqZm+z
 LOcnhZBNEJPK8gCNClvuGzZ78xrYeQ4vEKQeIuHU9mBjm5Fz46fTCTBbTrLrAAhnyASS
 r9vvK3HhGNOJLFYPjKX8F/oOscePbhVS3RhR82osCbkdCG55H0VhH27Clsuwv69lddC+
 1ey54ImZKopDeSCWBkwZS5tz7C9/Qwjc7lzep9hSKHH+4onj/8c9xjxfAM72KLaASjrv
 0u1+iDbWtOUHDGoRr6avWX5L2/MS+zrFV9WQyty8gknUqwvWhRdDhQl4OkTZpra4elCG
 R4ww==
X-Gm-Message-State: AOAM532tBf3LS3buEbiJhKoyaR0L7ynbdYyYsv32zF2Dx8GAeEQVbYXe
 ZTP2uGGwQ6xoZ7mdqUJ2se0=
X-Google-Smtp-Source: ABdhPJweuaiuwMxDS5YAkJqVVzQ5qqhWR6hrbxhku98V5b22Fjd7XY4pc0CdziCVk2EUT5CAF8RBaQ==
X-Received: by 2002:aa7:c850:: with SMTP id g16mr16813797edt.324.1618689181312; 
 Sat, 17 Apr 2021 12:53:01 -0700 (PDT)
Received: from philipps-macbook-pro.fritz.box (p57aafcaa.dip0.t-ipconnect.de.
 [87.170.252.170])
 by smtp.gmail.com with ESMTPSA id nd36sm6739304ejc.21.2021.04.17.12.52.59
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Sat, 17 Apr 2021 12:53:00 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: Philipp <p.stephani2@HIDDEN>
In-Reply-To: <83fszovhox.fsf@HIDDEN>
Date: Sat, 17 Apr 2021 21:52:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8491CEA9-E230-48E4-9AB3-71DF0B4D8A2B@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN> <83tuo4vqet.fsf@HIDDEN>
 <CAArVCkQq5Zrdk31wdoDmTSqbEc+aPHdLy8w9ZuZmzQ2t83NSjw@HIDDEN>
 <83r1j8vpku.fsf@HIDDEN>
 <CAArVCkT-xh4oJ5a1Bgctn62DMNK5_xw5+mg1jRZchV1Pcrq0bQ@HIDDEN>
 <83fszovhox.fsf@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>,
 45198 <at> debbugs.gnu.org, stefankangas@HIDDEN,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
 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: -0.8 (/)



> Am 17.04.2021 um 21:23 schrieb Eli Zaretskii <eliz@HIDDEN>:
>=20
>> From: Philipp Stephani <p.stephani2@HIDDEN>
>> Date: Sat, 17 Apr 2021 21:14:02 +0200
>> Cc: Mattias Engdeg=C3=A5rd <mattiase@HIDDEN>,=20
>> 	Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>,=20
>> 	45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>,=20=

>> 	Stefan Monnier <monnier@HIDDEN>, Alan Third =
<alan@HIDDEN>
>>=20
>>> "Performing computations" in Emacs corresponds to invoking gobs of
>>> system interfaces, and if we are going to filter most of them, I =
fear
>>> we will get a dysfunctional Emacs.  E.g., cursor blinking requires
>>> accessing the system time, displaying a busy cursor requires =
interval
>>> timers, profiling requires signals, and you cannot do anything in
>>> Emacs without being able to allocate memory.  If we leave Emacs only
>>> with capabilities to read and write to a couple of descriptors, how
>>> will the result be useful?
>>=20
>> We would definitely allow more stuff (e.g. some other syscalls are
>> required for Emacs to even start up). For example, Emacs needs to
>> allocate memory and thus needs mmap/sbrk. Timing functions are not
>> security-sensitive (timing attacks exist, but should be prevented in
>> this case by blocking any relevant use of the data such obtained), =
and
>> signals only affect the sandboxed Emacs process. The two big things =
we
>> need to prevent is writing arbitrary files and creating sockets.
>=20
> So you are going to suggest that we rely on some auditing of the
> syscalls Emacs uses now to decide which ones to filter and which not?

I don't mean that we should wade through all potential syscalls that =
Emacs could make.  Typically you can come up with such a Seccomp policy =
iteratively: run Seccomp in advisory mode (i.e. only log syscalls), then =
allow the syscalls that are both necessary and harmless in the policy.

> If so, how will this work in the future, when Emacs might decide to
> issue some additional syscalls? who and how will remember to update
> the filter definitions?

There are unit tests that ensure that the behavior we expect works.  For =
example, an existing unit test verifies that the sandboxed Emacs process =
can write to standard output (and it has already failed a few times on =
various systems, which is expected and is how we can find new syscalls =
to add).  So we only need to remember to run the unit tests (and have =
good test coverage).

>  And what about users who make local changes
> in their Emacs?

They can provide their own Seccomp policies or modify the ones included =
in Emacs.

>=20
>> At least initially we should only care about batch mode, though -
>> nothing prevents interactive mode in a sandbox in principle, but =
batch
>> mode is much easier to deal with, and suffices for the Flymake use
>> case.
>=20
> I understand why batch mode might be easier to deal with, but I'm not
> sure we should care more about it just because it's easier.

We care about it in the scope of the feature being discussed (Flymake) =
because Flymake runs Emacs in batch mode anyway.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:42:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 15:42:46 2021
Received: from localhost ([127.0.0.1]:44687 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXqq1-00018z-Pn
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:42:46 -0400
Received: from mail-ed1-f47.google.com ([209.85.208.47]:33567)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lXqpz-00018m-I3
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:42:40 -0400
Received: by mail-ed1-f47.google.com with SMTP id w18so36215541edc.0
 for <45198 <at> debbugs.gnu.org>; Sat, 17 Apr 2021 12:42:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=SUXfrS1TSswhuexYFf3ZyMUDHa1TSug4DSrNBXQ4asw=;
 b=gWb3r+q6hyuyq3dxa2KxDAui+zdWVaCDe+E+Bw4+BJul8KTJzQ26R8JTB7OfgXegLT
 W8KYtSe4YegFu5DBTqEBlDrWE7hRydxtK1gswqzjmSZX7NR2ivpA8cBXn9DTdLvpCQm1
 pPlesHFUaFkmJPcDRNiE7EAXbHpf+k6vg5C6lehwxcz9r9xmzcG4szqYM1Am8iY/OPqc
 JynJHOf82VvPMwMjWlhzThsCgRzS0/TxLB5FeZDJ98FR/WKIn16R9HxA76Yv0YPkCRUw
 hjG8cZbsOm6zlvkt9TOTy6jOBpuuFo3u5+Z8M6Lx+8LNTbp4wg0GQS3CZRVaaU7wAYqB
 vrRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=SUXfrS1TSswhuexYFf3ZyMUDHa1TSug4DSrNBXQ4asw=;
 b=AXCWHnza3ARZ3PQVBw0CSC5VMuM7b4wykS8o5ZQ6nNJoBpGcQifahZklIjqUjvg+j8
 nGYHiwA6u/mpfkRPu8AOJI/wCcT5MCvFJoeID/W2ijSOiyS7XH9X0HcQsej6OtYRtIi9
 lih5PFARuoL0kmU5JzZnEx/ENTMRY3SPuc9J1mgslt1Fw+BWGSUK+5SzND0joHqxuaLl
 +h2+9gfOHq/UroNcbeO6SXoXBx6P+aGB7Iv6WFEa5tKRoaNitvuu+zCH+HlN7M2tQ8d1
 aBgjJ4u53ixDCog1rvmSTaEeU0UT3DCi1usZjQ8ragIBk7tpafonkBl1saWgIu95u7M4
 Aeww==
X-Gm-Message-State: AOAM5304pXADQJvGhM8nt3OPMeKpKCyobRNdNCS+8MZWlbpnY9ejkgp2
 rxtMSTiPoHkjSWunE52jmfk=
X-Google-Smtp-Source: ABdhPJyEgAzczoacppgQR0YizxkGm4ZZr0jjAFIIk+eMEX0HkUjJ3BxxYRP25xC8ajpyEtgzGfBLxQ==
X-Received: by 2002:a05:6402:4245:: with SMTP id
 g5mr17098282edb.306.1618688553556; 
 Sat, 17 Apr 2021 12:42:33 -0700 (PDT)
Received: from philipps-macbook-pro.fritz.box (p57aafcaa.dip0.t-ipconnect.de.
 [87.170.252.170])
 by smtp.gmail.com with ESMTPSA id d5sm3969607edt.49.2021.04.17.12.42.31
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Sat, 17 Apr 2021 12:42:32 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: Philipp <p.stephani2@HIDDEN>
In-Reply-To: <78F41D0B-D2F6-444C-9B5C-9C50CFF2CFBD@HIDDEN>
Date: Sat, 17 Apr 2021 21:42:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E967667D-698C-47FE-9E95-429C30C83907@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN>
 <jwvim4k6ade.fsf-monnier+emacs@HIDDEN>
 <78F41D0B-D2F6-444C-9B5C-9C50CFF2CFBD@HIDDEN>
To: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@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 17.04.2021 um 20:59 schrieb Mattias Engdeg=C3=A5rd =
<mattiase@HIDDEN>:
>=20
> 17 apr. 2021 kl. 20.21 skrev Stefan Monnier =
<monnier@HIDDEN>:
>=20
>>> Very reasonable. Or would you prefer having the sandboxing in =
flymake?
>>=20
>> AFAICT this question refers to a minor implementation detail ;-)
>=20
> Of course, sorry.
>=20
> Looks like I forgot to attach the updated patch in a previous message. =
Here it is.
>=20
> <0001-Add-macOS-sandboxing-bug-45198.patch>

Looks generally fine, just a few minor comments.


> diff --git a/lisp/subr.el b/lisp/subr.el
> index c2be26a15f..196512c0c6 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el

Should this maybe be in a platform-specific file such as ns-fns.el (like =
dos-fns.el, w32-fns.el)?

> @@ -6262,4 +6262,22 @@ internal--format-docstring-line
>  This is intended for internal use only."
>    (internal--fill-string-single-line (apply #'format string =
objects)))
> =20
> +(when (eq system-type 'darwin)
> +  (defun darwin-sandbox-enter (dirs)

I don't think we use the "darwin-" prefix anywhere else in Emacs.  Maybe =
use a "ns-" prefix.
Also I think such internal functions commonly have an "internal" piece =
somewhere in their name, e.g. "ns-enter-sandbox-internal".

> +    "Enter a sandbox only permitting reading files under DIRS.
> +DIRS is a list of directory names.  Most other operations such as
> +writing files and network access are disallowed.
> +Existing open descriptors can still be used freely.
> +
> +This is not a supported interface and is for internal use only."
> +    (darwin-sandbox-init

Can you also refer to the documents listed below, so that readers aren't =
wondering what this syntax means?

> +     (concat "(version 1)\n"

Since this uses Lisp syntax, maybe use (prin1-to-string `(...))?

> +             "(deny default)\n"
> +             ;; Emacs seems to need /dev/null; allowing it does no =
harm.
> +             "(allow file-read* (path \"/dev/null\"))\n"
> +             (mapconcat (lambda (dir)
> +                          (format "(allow file-read* (subpath %S))\n" =
dir))

Are you sure that the string quoting syntaxes are compatible?  We really =
need to avoid injection attacks here.

> +                        dirs ""))))
> +  )
> +
>  ;;; subr.el ends here
> diff --git a/src/sysdep.c b/src/sysdep.c
> index d940acc4e0..44e8b82bc6 100644
> --- a/src/sysdep.c
> +++ b/src/sysdep.c
> @@ -4286,8 +4286,40 @@ str_collate (Lisp_Object s1, Lisp_Object s2,
>  }
>  #endif	/* WINDOWSNT */
> =20
> +#ifdef DARWIN_OS
> +
> +/* This function prototype is not in the platform header files.
> +   See =
https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0=
.pdf
> +   and =
https://chromium.googlesource.com/chromium/src/+/master/sandbox/mac/seatbe=
lt_sandbox_design.md */

Thanks, I'd expect at least the Chromium reference to stick around.

> +int sandbox_init_with_parameters(const char *profile,
> +                                 uint64_t flags,
> +                                 const char *const parameters[],
> +                                 char **errorbuf);
> +
> +DEFUN ("darwin-sandbox-init", Fdarwin_sandbox_init, =
Sdarwin_sandbox_init,

Similar comments about naming here; maybe call this =
ns-init-sandbox-internal or so.

> +       1, 1, 0,
> +       doc: /* Enter a sandbox whose permitted access is curtailed by =
PROFILE.
> +Already open descriptors can be used freely.
> +PROFILE is a string in the macOS sandbox profile language,
> +a set of rules in a Lisp-like syntax.

I'd also refer to the Chromium document here, otherwise C-h f for this =
function won't be very useful.

> +
> +This is not a supported interface and is for internal use only. */)
> +  (Lisp_Object profile)
> +{
> +  CHECK_STRING (profile);
> +  char *err =3D NULL;
> +  if (sandbox_init_with_parameters (SSDATA (profile), 0, NULL, &err) =
!=3D 0)

If you're using SSDATA, better check that the string doesn't contain =
embedded null bytes.
Also does this need to be encoded somehow?  What happens if the string =
contains non-Unicode characters like raw bytes?

> +    error ("sandbox error: %s", err);

This looks like an error that clients could handle, so I'd signal a =
specific error symbol here.

> +  return Qnil;
> +}
> +
> +#endif	/* DARWIN_OS */
> +
>  void
>  syms_of_sysdep (void)
>  {
>    defsubr (&Sget_internal_run_time);
> +#ifdef DARWIN_OS
> +  defsubr (&Sdarwin_sandbox_init);
> +#endif
>  }
> diff --git a/test/src/emacs-tests.el b/test/src/emacs-tests.el

This should probably be in subr-tests.el since it tests a function in =
subr.el.

> index 09f9a248ef..c1a741c359 100644
> --- a/test/src/emacs-tests.el
> +++ b/test/src/emacs-tests.el
> @@ -210,4 +210,74 @@ emacs-tests/bwrap/allows-stdout
>            (should (eql status 0)))
>          (should (equal (string-trim (buffer-string)) "Hi"))))))
> =20
> +(defun emacs-tests--darwin-run-sandboxed-emacs (sandbox-dirs body)
> +  "Run Emacs and evaluate BODY, only allowing reads from =
SANDBOX-DIRS.
> +If SANDBOX-DIRS is `no-sandbox', then run without sandbox.
> +Return (EXIT-STATUS . OUTPUT), where OUTPUT is stderr and stdout."
> +  (let ((emacs (expand-file-name invocation-name =
invocation-directory))
> +        (process-environment nil))
> +    (with-temp-buffer
> +      (let* ((prog `(progn
> +                      ,@(and (not (eq sandbox-dirs 'no-sandbox))
> +                             `((darwin-sandbox-enter =
',sandbox-dirs)))
> +                      ,@body))
> +             (res (call-process emacs nil t nil
> +                                "--quick" "--batch"
> +                                (format "--eval=3D%S" prog))))
> +        (cons res (buffer-string))))))

This is more of a personal style, feel free to ignore:
I like tests that are somewhat repetitive but more decoupled and easier =
to read better than tests with factored-out assertions.  See e.g. the =
arguments in =
https://www.maaikebrinkhof.nl/2016/03/repetition-in-testing/ and =
https://stackoverflow.com/a/130038.

> +
> +(ert-deftest emacs-tests/darwin-sandbox ()
> +  (skip-unless (eq system-type 'darwin))
> +  (emacs-tests--with-temp-file test-file ("test")
> +    (let ((some-text "abcdef")
> +          (other-text "ghijkl")
> +          (test-file (file-truename test-file)))   ; resolve symlinks
> +      (with-temp-buffer
> +        (insert some-text)
> +        (write-file test-file))
> +
> +      ;; Read the file without allowing its directory -- should fail.
> +      (let ((res-out (emacs-tests--darwin-run-sandboxed-emacs
> +                      nil
> +                      `((find-file-literally ,test-file)
> +                        (message "OK: %s" (buffer-string))))))
> +        (ert-info ((cdr res-out) :prefix "output: ")
> +          (should-not (equal (car res-out) 0))
> +          (should-not (string-search some-text (cdr res-out)))))
> +
> +      ;; Read the file allowing its directory -- should succeed.
> +      (let ((res-out (emacs-tests--darwin-run-sandboxed-emacs
> +                      (list (file-name-directory test-file))
> +                      `((find-file-literally ,test-file)
> +                        (message "OK: %s" (buffer-string))))))
> +        (should (equal res-out (cons 0 (format "OK: %s\n" =
some-text)))))
> +
> +      ;; Write to the file allowing directory reads -- should fail.
> +      (let ((res-out (emacs-tests--darwin-run-sandboxed-emacs
> +                      (list (file-name-directory test-file))
> +                      `((with-temp-buffer
> +                          (insert ,other-text)
> +                          (write-file ,test-file))))))
> +        (ert-info ((cdr res-out) :prefix "output: ")
> +          (should-not (equal (car res-out) 0))
> +          ;; The file should be unchanged.
> +          (let ((contents (with-temp-buffer
> +                            (insert-file-contents-literally =
test-file)
> +                            (buffer-string))))
> +            (should (equal contents some-text)))))
> +
> +      ;; Write to the file without sandbox -- should succeed.
> +      (let ((res-out (emacs-tests--darwin-run-sandboxed-emacs
> +                      'no-sandbox
> +                      `((with-temp-buffer
> +                          (insert ,other-text)
> +                          (write-file ,test-file))))))
> +        (ert-info ((cdr res-out) :prefix "output: ")
> +          (should (equal (car res-out) 0))
> +          ;; The file should be changed.
> +          (let ((contents (with-temp-buffer
> +                            (insert-file-contents-literally =
test-file)
> +                            (buffer-string))))
> +            (should (equal contents other-text))))))))

These should be four separate tests, as they test four separate things.=

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:23:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 15:23:53 2021
Received: from localhost ([127.0.0.1]:44666 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXqXo-0000gX-L8
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:23:52 -0400
Received: from eggs.gnu.org ([209.51.188.92]:52554)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lXqXm-0000gK-C6
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:23:50 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:38923)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lXqXd-0004m1-HX; Sat, 17 Apr 2021 15:23:42 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2806
 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 1lXqXd-0003Vt-07; Sat, 17 Apr 2021 15:23:41 -0400
Date: Sat, 17 Apr 2021 22:23:26 +0300
Message-Id: <83fszovhox.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <CAArVCkT-xh4oJ5a1Bgctn62DMNK5_xw5+mg1jRZchV1Pcrq0bQ@HIDDEN>
 (message from Philipp Stephani on Sat, 17 Apr 2021 21:14:02 +0200)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <83v98kvr7y.fsf@HIDDEN> <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <83tuo4vqet.fsf@HIDDEN>
 <CAArVCkQq5Zrdk31wdoDmTSqbEc+aPHdLy8w9ZuZmzQ2t83NSjw@HIDDEN>
 <83r1j8vpku.fsf@HIDDEN>
 <CAArVCkT-xh4oJ5a1Bgctn62DMNK5_xw5+mg1jRZchV1Pcrq0bQ@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org,
 stefankangas@HIDDEN, joaotavora@HIDDEN, 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.7 (-)

> From: Philipp Stephani <p.stephani2@HIDDEN>
> Date: Sat, 17 Apr 2021 21:14:02 +0200
> Cc: Mattias Engdegård <mattiase@HIDDEN>, 
> 	João Távora <joaotavora@HIDDEN>, 
> 	45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>, 
> 	Stefan Monnier <monnier@HIDDEN>, Alan Third <alan@HIDDEN>
> 
> > "Performing computations" in Emacs corresponds to invoking gobs of
> > system interfaces, and if we are going to filter most of them, I fear
> > we will get a dysfunctional Emacs.  E.g., cursor blinking requires
> > accessing the system time, displaying a busy cursor requires interval
> > timers, profiling requires signals, and you cannot do anything in
> > Emacs without being able to allocate memory.  If we leave Emacs only
> > with capabilities to read and write to a couple of descriptors, how
> > will the result be useful?
> 
> We would definitely allow more stuff (e.g. some other syscalls are
> required for Emacs to even start up). For example, Emacs needs to
> allocate memory and thus needs mmap/sbrk. Timing functions are not
> security-sensitive (timing attacks exist, but should be prevented in
> this case by blocking any relevant use of the data such obtained), and
> signals only affect the sandboxed Emacs process. The two big things we
> need to prevent is writing arbitrary files and creating sockets.

So you are going to suggest that we rely on some auditing of the
syscalls Emacs uses now to decide which ones to filter and which not?
If so, how will this work in the future, when Emacs might decide to
issue some additional syscalls? who and how will remember to update
the filter definitions?  And what about users who make local changes
in their Emacs?

> At least initially we should only care about batch mode, though -
> nothing prevents interactive mode in a sandbox in principle, but batch
> mode is much easier to deal with, and suffices for the Flymake use
> case.

I understand why batch mode might be easier to deal with, but I'm not
sure we should care more about it just because it's easier.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:21:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 15:21:35 2021
Received: from localhost ([127.0.0.1]:44657 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXqVb-0000cs-0d
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:21:35 -0400
Received: from mail-ot1-f42.google.com ([209.85.210.42]:38481)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lXqVZ-0000ce-AO
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:21:33 -0400
Received: by mail-ot1-f42.google.com with SMTP id
 e89-20020a9d01e20000b0290294134181aeso3061454ote.5
 for <45198 <at> debbugs.gnu.org>; Sat, 17 Apr 2021 12:21:33 -0700 (PDT)
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=UlypKpaTBFNvIMIo1Nn1RHKTPh3d9FkdXdPyNNEebk4=;
 b=spkF/VMZ8q9sunzOvfLEFgFhUExz6IfQrjboELbHhruhBCG9rEefBn8+hp0WkwqN63
 ExI1Dh6eu1TJBns9vKEQTrabFB/kBk6uAat83cLG5WLJrXjKYbPFHXwFQbfkyMwvTLMV
 w19TtDIud6SsoCDsIbr5TfNpNRjcAE5hjKc32UHBKPfkBIerGiWxEcd/yxUASQK564R5
 6bAk0o4moTfmkpULqpvtC3LBHPPmIcnd770xs2g1l2NMhpuTBmaZiZZnWfTFV8ijbvSY
 9gp4Rr4M76Q/md1f70SmqlDsGHesL9r5EUnpHbnxVD2+ct8IdNpl1jS4+oC1Vitd4At7
 JcYw==
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=UlypKpaTBFNvIMIo1Nn1RHKTPh3d9FkdXdPyNNEebk4=;
 b=aXeshdgK4+GgzEPBJnO+9BtkfM8FdadPiJXso5DxIb4OVaXl84zkP+VWj6yahgl/Bw
 A3B599Hp0bprH08GohzH37yqpxcwILg3lZc25LrDD7rVPBFm8cGhfgV30A5kXlWbiBC/
 YqyVKfWLNOtG826F1I7myGTEJ8Id+LAHG6mnOZW89kKGIgGCYmchTYtqYsoJ9JggPHEs
 VCZWkWTtXAv6RkaQcx/ITiFXJfVRWMVANNbMazZTFK74ipAYeJetjT2mGnkkfY8V/zwl
 2qy/5XAzNLMGoqZuThxBpIu8r0jynSCF9zp8Y0nIrU3EpTAokQWAuwz0x76hjwI7C8Qb
 j7iQ==
X-Gm-Message-State: AOAM532vhcUA/oJjlVm63xRT3ffBb71SFaZvK2p5fjZV7Nymo2G9PhRW
 Arkt8MlnZmsJrdw5EXTzZW7jLKv85D5RAkH38tI=
X-Google-Smtp-Source: ABdhPJxtWSUeO0Uy70jv6wY4NOpmuPPY68UTKkTM6Uqtxc6amF1erIfqpo7p6GvJtOsVdjTdRMXKW8qt7fO5Z0kBm7w=
X-Received: by 2002:a05:6830:4121:: with SMTP id
 w33mr8569588ott.153.1618687287755; 
 Sat, 17 Apr 2021 12:21:27 -0700 (PDT)
MIME-Version: 1.0
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <077448DE-3E4E-4821-8F5C-5CA62BF217E5@HIDDEN>
 <jwvzgxw6bl8.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvzgxw6bl8.fsf-monnier+emacs@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 17 Apr 2021 21:21:16 +0200
Message-ID: <CAArVCkRA-xBkVgGzaytx6zngWpsWZP+D2G7S2acM+MvHpNc=LA@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: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>,
 45198 <at> debbugs.gnu.org, Stefan Kangas <stefan@HIDDEN>,
 Alan Third <alan@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 Sa., 17. Apr. 2021 um 19:57 Uhr schrieb Stefan Monnier
<monnier@HIDDEN>:
>
> >> As we gain more experience with these sandboxing mechanisms, we can look
> >> at relaxing these restrictions, but I think initially we should
> >> be conservative.
> >
> > I take the opposite view, but our goals are the same and we will converge.
>
> I guess the conversion goes like:
> - define "low-level" interfaces to OS-specific functionality.  They can
>   be as close to the OS's own featureset as we want.  They don't
>   really need to be stable over time (especially not at the beginning).

I guess it would still make sense to stabilize them with Emacs 28.
These interfaces can be useful in their own right, and I guess people
will start using them once available.

> - define an OS-agnostic API on top of them.  This one needs to be
>   conservative and should evolve more slowly, paying attention to
>   backward compatibility.
>
>

Yes.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:19:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 15:19:54 2021
Received: from localhost ([127.0.0.1]:44651 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXqTy-0000ZZ-L4
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:19:54 -0400
Received: from mail-oi1-f181.google.com ([209.85.167.181]:33397)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lXqTx-0000ZO-Jy
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:19:53 -0400
Received: by mail-oi1-f181.google.com with SMTP id l131so26398992oih.0
 for <45198 <at> debbugs.gnu.org>; Sat, 17 Apr 2021 12:19:53 -0700 (PDT)
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=Ui8F8rSDXUU0+2TtgS0qCZ5bnr0trQvRNjtgldxJAHs=;
 b=PKXQR96onIOTna9VMp9DJnkquBG7vgux5dCXKNK1vLiIkDcU2OVshBQbpWMmJv2xsY
 6kRkEzhK7JWFfnnVNYnSZsDgFPsnn/jTKeR7DNAr8IUPruGzMbrvdva2EUEjiBsjhLvd
 tEkgsugdoLdqMlehKic1WirReOZ+yEKU4lzilH28wWMOdYV5MaOVOx13+7ZJUpwK9gMQ
 e6QtEuLOtC9ayHSEHUX9qZBuVMd62g3CHjV27tV5YRLdj5aids1jKW7cSmLbaYK9uLhy
 zKAxpjJEU08jTbbcGdrQSwHQjJ5gofvwwEJmRkCIVN2BKig1UGtuQyH/qo84PnZSB6pf
 kkgw==
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=Ui8F8rSDXUU0+2TtgS0qCZ5bnr0trQvRNjtgldxJAHs=;
 b=uWHMtSAqgQNpaTPNr4NNTiRlA32BxbRhCnXTdJuMTzMhkIRd0WN9L0m1/tJnJwZaBA
 H3IqP+Cjt4cnvw8wHNXWTDOx59aXlq97bh/CNpn5kAG9r0v3YAtbBU4jOxqsDgygXyQ9
 zl0Ez0WRxfmR4ZKT6i/XXa6sWbk9LKUvST5h9To+/3mpGS9u1nakoLzQACxA5QdY4Maz
 La3A4z8F4ghG9UHgQjzca+fTWLDHgTJPFOsxe/nNlBC4ZeoFdxhI6+mSoamzE9ScB+eC
 CHLYAMmJlzacopJyE+Yy1xnC9NrPZ7A8vHgMpchCUw3yvQgE/3V41PrjQ9g6YI7kvU3T
 mq2A==
X-Gm-Message-State: AOAM533cV8GVq9OeWkJz04Twh0J4s49AC1+3Iaz2Sukeu86pgLEUk+vN
 EZvAf8cGXQH5x9BXVLMIiSp4MByTORnGd4TNM60=
X-Google-Smtp-Source: ABdhPJzxdR2MdvIpmGysf2aVVMty+y/8QYWs07GdiMDSew0X2jGZXPzHPAQNJ23ulmGVKvpbRyQ7ahImmAfdaMgSxDU=
X-Received: by 2002:a54:4582:: with SMTP id z2mr10904177oib.158.1618687188092; 
 Sat, 17 Apr 2021 12:19:48 -0700 (PDT)
MIME-Version: 1.0
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <83v98kvr7y.fsf@HIDDEN> <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN>
In-Reply-To: <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 17 Apr 2021 21:19:37 +0200
Message-ID: <CAArVCkSQsWT+TaXjj4xGYSg+5x+QXdJf0Ogfo_yQeoEME7CMng@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: Alan Third <alan@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
 Eli Zaretskii <eliz@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: -0.8 (/)

Am Sa., 17. Apr. 2021 um 19:48 Uhr schrieb Mattias Engdeg=C3=A5rd <mattiase=
@acm.org>:
>
> 17 apr. 2021 kl. 18.10 skrev Philipp <p.stephani2@HIDDEN>:
>
> > (cl-defun start-sandbox (function &key readable-directories stdout-buff=
er) ...)
> > (defun wait-for-sandbox (sandbox) ...)
> >
> > where start-sandbox returns an opaque sandbox object running FUNCTION t=
hat wait-for-sandbox can wait for.  That should be generic enough that it's=
 extensible and implementable on several platforms, and doesn't lock us int=
o specific implementation choices.
>
> That's probably a nice interface. A slightly more low-level mechanism is =
what I had in mind, a `make-process` variant that starts an Emacs subproces=
s with the required arguments to set up a sandbox and leaving it to the use=
r to supply remaining arguments. But maybe we are really talking about more=
 or less the same thing.

Yes, that would essentially be how start-sandbox would get
implemented. In the Seccomp case, something like (conceptually)
(start-process "bwrap ... -- emacs --seccomp=3D... --quick --batch
--eval=3DFUNCTION")
where bwrap can set up mount namespaces to restrict the filesystem.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:17:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 15:17:18 2021
Received: from localhost ([127.0.0.1]:44633 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXqRS-0000Uy-2F
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:17:18 -0400
Received: from mail-oi1-f172.google.com ([209.85.167.172]:38743)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lXqRQ-0000Ul-AY
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:17:16 -0400
Received: by mail-oi1-f172.google.com with SMTP id b3so16670258oie.5
 for <45198 <at> debbugs.gnu.org>; Sat, 17 Apr 2021 12:17:16 -0700 (PDT)
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=nIoZfurH2fSj/N2kyoXQ/C9rMXi9bnzR1Il8xlU6ywo=;
 b=RbI0RgSCSgpbKDCAXqDZkBHN/Ud1HG8XMQeKscv9BHVAP+Ge3oihn0QbJi97ynRLKT
 sqt5cB2ix/l7AC6Hef4JsLkxx7mWy0Q2ryaPyLvCm7ctdqCqEg4Qbs9xHHQtVBur6sCu
 GXfUPVbMMc9Ad3piu52L85ZM/s4d4NXyIGzM+VAmPvwvW84nVeHC1Eyt5MzPnxfXPXQz
 LQ06gMVjyWufKzuvcoiMqOOWY8IwnqDQtnc1d3yrCcDDU8BuJ/rPhIdsMMaWalCWopZa
 paazvHEgsMA6prgOsnIac3RuXXDH+efcr6ZPd+kHrsO3MQEP65f+pOvHDwBaVCmBHnvM
 3HXw==
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=nIoZfurH2fSj/N2kyoXQ/C9rMXi9bnzR1Il8xlU6ywo=;
 b=JrwbGgVmIarDmsoIvCSDEcXwJBkawomMwzoL8/sad1ZQe2XwgAjy4hD3UJOPu9NMIK
 EShGohaq60Mrynj8LO9TrnWOhmholO92QxM9YvLTthM9fyRNRA3ZqLjIeI8jURSsXjEn
 ndQpZt4OajLUhN0prHKqsXDuJmS1BKnb7qvHBgCuQ+RThvAvVqZZelBFRhQxr5YA79S+
 CIRZch1IJP88J6hYAA36rrvbsw+PWVJksqofU12jQIz8m9A3TmmPjwbUfn5pG9e4xeMC
 FQaguszvzL2ZqnZHTSOOsH9jpy5ZjHJseOtk9bcB1QiCD+MSTaJNwcATp8D7Ruvn+iTW
 1EBA==
X-Gm-Message-State: AOAM533MA69xn2vj1aJBaNMhmGHNepW7ztQAJHEjKa66l0LH+SnqcRUP
 i8LqcrBJi/tVaMxtPFOiXPCvdcBwMSBP1JcXC2U=
X-Google-Smtp-Source: ABdhPJw2U9NXFWTpwoaXuVy5tEjjwZvZIQGhVTCs47AcFcWtGaobGJ4Dm0I4FQ0c5LD0c/OVNvQxcAKTDEOW27x4PQA=
X-Received: by 2002:aca:1814:: with SMTP id h20mr10680934oih.150.1618687030888; 
 Sat, 17 Apr 2021 12:17:10 -0700 (PDT)
MIME-Version: 1.0
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <077448DE-3E4E-4821-8F5C-5CA62BF217E5@HIDDEN>
In-Reply-To: <077448DE-3E4E-4821-8F5C-5CA62BF217E5@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 17 Apr 2021 21:16:59 +0200
Message-ID: <CAArVCkTxLx2Mmap-F_cEzi1gPJBqA7_mpydFLKTqXFnNiAp_4A@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: 45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>,
 Alan Third <alan@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.8 (/)

Am Sa., 17. Apr. 2021 um 19:22 Uhr schrieb Mattias Engdeg=C3=A5rd <mattiase=
@acm.org>:
> > As we gain more experience with these sandboxing mechanisms, we can loo=
k at relaxing these restrictions, but I think initially we should be conser=
vative.
>
> I take the opposite view, but our goals are the same and we will converge=
.

As long as they converge before releasing Emacs 28, fine. After that
it will be very difficult to restrict an initially-open interface.

> >> +Already open descriptors can be used freely. */)
> >
> > What does this mean?  Emacs doesn't really expose file descriptors to u=
sers.
>
> It sort of does (in the form of processes), but there could also be descr=
iptors not directly exposed. It would be incomplete not to mention the poss=
ibility. It looks like the seccomp filter generator uses the same policy, t=
reating descriptors as capabilities.

Yes, but since it's only a command-line flag right now, there
shouldn't be any open file descriptors except the standard ones, so
this specific bit of complexity is avoided.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:14:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 15:14:37 2021
Received: from localhost ([127.0.0.1]:44619 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXqOn-0000Pd-9I
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:14:37 -0400
Received: from eggs.gnu.org ([209.51.188.92]:50786)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lXqOl-0000PQ-9w
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:14:31 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:38717)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lXqOf-0007eA-0M; Sat, 17 Apr 2021 15:14:25 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2235
 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 1lXqOe-0002YY-CL; Sat, 17 Apr 2021 15:14:24 -0400
Date: Sat, 17 Apr 2021 22:14:09 +0300
Message-Id: <83im4kvi4e.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwv7dl069cy.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 17 Apr 2021 14:47:34 -0400)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <jwva6pwalxc.fsf-monnier+emacs@HIDDEN> <83o8ecvnok.fsf@HIDDEN>
 <jwv5z0k7qeg.fsf-monnier+emacs@HIDDEN> <83lf9gvktv.fsf@HIDDEN>
 <jwv7dl069cy.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 p.stephani2@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: -1.7 (-)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: mattiase@HIDDEN,  joaotavora@HIDDEN,  p.stephani2@HIDDEN,
>   stefan@HIDDEN,  45198 <at> debbugs.gnu.org,  alan@HIDDEN
> Date: Sat, 17 Apr 2021 14:47:34 -0400
> 
> >> Normally, this untrusted ELisp code (the one present within
> >> `eval-when-compile` and macros defined within the file) limits itself to
> >> quite simple sexp manipulation, so the sandboxing can be quite
> >> restrictive, disallowing things like user interaction, uses of
> >> subprocesses, or writing to files.
> > How is this different from byte-compiling some code, e.g. one
> > downloaded from some elpa?
> 
> The normal way to enable flymake is something like
> 
>     (add-hook 'emacs-lisp-mode #'flymake-mode)
> 
> so the file gets compiled just because you're looking at it.
> That's quite different from an explicit request from the user to compile
> a file.

It is?  Sorry, I don't see the difference, not a significant one.  If
you are implying that one does something conscious and deliberate
before byte-compiling a file, then one could also remove Flymake from
the hook while at that.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:14:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 15:14:22 2021
Received: from localhost ([127.0.0.1]:44616 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXqOb-0000PE-UE
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:14:22 -0400
Received: from mail-oi1-f176.google.com ([209.85.167.176]:33566)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lXqOZ-0000P1-Gm
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:14:20 -0400
Received: by mail-oi1-f176.google.com with SMTP id l131so26389818oih.0
 for <45198 <at> debbugs.gnu.org>; Sat, 17 Apr 2021 12:14:19 -0700 (PDT)
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=7i4zwekH/SOmp47Odq46RfyKqQQAKHZjjgO0KhadM88=;
 b=AAfiPJe9ISmfdxdZl7fAqZW7HANbxqIzvRLJ80dH9vcP9v9s1noGc42k2kLLrka7Fw
 Xf9oHES7ifv0fME8vwIaCIoVgRjrxZ+T64UahogZEANYM+V9BL7lbby+3KzeI978M1Bo
 RBLGksGXq+OisiISGQ//DZok0tpQitXTDVp9ACrcr3Vtsa6KSF9X70Y0Ew3/Z6NhGSDZ
 F2CAy8Vdm+o5OOXkVosrpKpGUD0CQTwNYBu8g1WxMe+mng2jEKGDieWHbKvcRhXIlpWU
 HGNzN+crD2BSONdqeMQoWl/CqgHhTXrz8sZjz1rAVdjp3VVz+7vdGaHOqBDfASsD+cCc
 ZDUg==
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=7i4zwekH/SOmp47Odq46RfyKqQQAKHZjjgO0KhadM88=;
 b=U0DkR5CEE3MQeqc8rxHzBJEo2Uo6KzeWkHqSSWvDqldirw9i8cpbLj6Mf1yr0IpNsf
 rVB1eTCA8qCWfpo/sbw0AcP2smwRmPXXdY1KtfyiWFCaMQa1zBXwGPxC939pfEgeF1Yt
 arOouyOq9+N29OdGk2JJHcq1GF24f2nfAtpgfdMWFOKweZeDPAh6Ups4TV82wtVwUbVY
 Yy9SfX0bLqpvrA5Y18Mu7BFM+/DfUKXJ49mr/3VovUyi6VxhLLSv+qLdnqFZRdKEgPho
 tTEI3g6lHwQlup069C9QZzfRdUuy7ZG6edUi+iUOGrFL5X51Gc2iLt6xuHhrp1MPj13E
 lwew==
X-Gm-Message-State: AOAM532B9TdOz2uGBkHEYdn80N+RsMoJrPpwoXTysby+OceMAxN5UF7G
 AIlu7HsDfB1o6jf46HCsy70ABlhmOwpBOVuC6go=
X-Google-Smtp-Source: ABdhPJy8YQKW6XTl8wa+/fFCGwShE4psCRdmLu3oAl6kCu7v/fcpZ6AOr0hhyrk0KWEMgt/qzP5LHRqwQtvzdDwjh2U=
X-Received: by 2002:aca:1814:: with SMTP id h20mr10675550oih.150.1618686853920; 
 Sat, 17 Apr 2021 12:14:13 -0700 (PDT)
MIME-Version: 1.0
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <83v98kvr7y.fsf@HIDDEN> <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <83tuo4vqet.fsf@HIDDEN>
 <CAArVCkQq5Zrdk31wdoDmTSqbEc+aPHdLy8w9ZuZmzQ2t83NSjw@HIDDEN>
 <83r1j8vpku.fsf@HIDDEN>
In-Reply-To: <83r1j8vpku.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 17 Apr 2021 21:14:02 +0200
Message-ID: <CAArVCkT-xh4oJ5a1Bgctn62DMNK5_xw5+mg1jRZchV1Pcrq0bQ@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: Alan Third <alan@HIDDEN>,
 =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@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: -0.8 (/)

Am Sa., 17. Apr. 2021 um 18:33 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
>
> > From: Philipp Stephani <p.stephani2@HIDDEN>
> > Date: Sat, 17 Apr 2021 18:20:15 +0200
> > Cc: Mattias Engdeg=C3=A5rd <mattiase@HIDDEN>,
> >       Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>,
> >       45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>,
> >       Stefan Monnier <monnier@HIDDEN>, Alan Third <alan@idioc=
y.org>
> >
> > That's a fair statement, and I'll try to answer here (and hopefully
> > later in the other thread as well). The sandbox should be able to
> > perform operations that are in some sense not security-relevant:
> > mostly performing computations, reading some necessary files, and
> > writing some diagnostics to standard output. The initial use case can
> > be running byte compilation in a Flymake backend. This would allow us
> > to enable Flymake byte compilation support by default, even on
> > untrusted code, because due to the sandbox that code could never
> > perform harmful operations. The Flymake backend would then use the
> > high-level sandbox functions to asynchronously start byte compilation
> > in a sandbox. The start-sandbox function in turn would launch an Emacs
> > subprocess using bwrap or similar to set up appropriate mount
> > namespaces and apply a Seccomp filter (in the GNU/Linux case).
>
> Thanks.  I think I understand the general idea, but not how to
> translate that into real life.
>
> "Performing computations" in Emacs corresponds to invoking gobs of
> system interfaces, and if we are going to filter most of them, I fear
> we will get a dysfunctional Emacs.  E.g., cursor blinking requires
> accessing the system time, displaying a busy cursor requires interval
> timers, profiling requires signals, and you cannot do anything in
> Emacs without being able to allocate memory.  If we leave Emacs only
> with capabilities to read and write to a couple of descriptors, how
> will the result be useful?

We would definitely allow more stuff (e.g. some other syscalls are
required for Emacs to even start up). For example, Emacs needs to
allocate memory and thus needs mmap/sbrk. Timing functions are not
security-sensitive (timing attacks exist, but should be prevented in
this case by blocking any relevant use of the data such obtained), and
signals only affect the sandboxed Emacs process. The two big things we
need to prevent is writing arbitrary files and creating sockets.
At least initially we should only care about batch mode, though -
nothing prevents interactive mode in a sandbox in principle, but batch
mode is much easier to deal with, and suffices for the Flymake use
case.

>  Even if Flymake byte compilation can live
> in such a sandbox (and I'm not yet certain it can), is that the most
> important situation where untrusted code could be run by Emacs?

It's at least the situation described here, and I think it's pretty
important. Another potential use case would be to allow some
buffer-local evaluation.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 18:59:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 14:59:19 2021
Received: from localhost ([127.0.0.1]:44584 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXqA3-0006L2-7S
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:59:19 -0400
Received: from mail1470c50.megamailservers.eu ([91.136.14.70]:55406
 helo=mail102c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1lXqA0-0006Ko-Uw
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:59:18 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1618685950;
 bh=b5FxU/n930a4X9c88pTflNr9aY8MlAuUkgdLo4uM7c8=;
 h=From:Subject:Date:In-Reply-To:Cc:To:References:From;
 b=KNYdLciklRVgntmONMTGk8HVxuktMc0yfeV8EW0LYTaGT6V+2ScKXP5gMVO8Em3lx
 VFJbmCJj4MhwSxBGMm9dI9ctlA88HyCrJlH1KqeECJD0sVxEtNaqnfZv5JxOsFSz/S
 xINn/9YWBVvbEAzFL6JRQvkgNoYEf+oKTdFFMNqA=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-b952e353.032-75-73746f71.bbcust.telenor.se
 [83.227.82.185]) (authenticated bits=0)
 by mail102c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 13HIx6Et030602; 
 Sat, 17 Apr 2021 18:59:08 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Message-Id: <78F41D0B-D2F6-444C-9B5C-9C50CFF2CFBD@HIDDEN>
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_64FD6A78-046E-4E8B-8A46-7F258849914F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Date: Sat, 17 Apr 2021 20:59:06 +0200
In-Reply-To: <jwvim4k6ade.fsf-monnier+emacs@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN>
 <jwvim4k6ade.fsf-monnier+emacs@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A742F21.607B2FFE.0009, 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=KN0k82No c=1 sm=1 tr=0 a=von4qPfY+hyqc0zmWf0tYQ==:117
 a=von4qPfY+hyqc0zmWf0tYQ==:17 a=M51BFTxLslgA:10 a=iRZporoAAAAA:8
 a=a2_K_BZEX7mNdVaJnwQA:9 a=CjuIK1q_8ugA:10 a=ENOmLqmOUNYA:10
 a=wlUJtMPZQSMOdi7ZWyMA:9 a=B2y7HmGcmWMA:10 a=NOBgFS-JBQ2l-kSd6-zu:22
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: 17 apr. 2021 kl. 20.21 skrev Stefan Monnier
 <monnier@HIDDEN>:
 >> Very reasonable. Or would you prefer having the sandboxing in flymake?
 > > AFAICT this question refers to a minor implementation detail ;-) 
 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: alan@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 Philipp <p.stephani2@HIDDEN>, joaotavora@HIDDEN,
 Eli Zaretskii <eliz@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 (/)


--Apple-Mail=_64FD6A78-046E-4E8B-8A46-7F258849914F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

17 apr. 2021 kl. 20.21 skrev Stefan Monnier <monnier@HIDDEN>:

>> Very reasonable. Or would you prefer having the sandboxing in =
flymake?
>=20
> AFAICT this question refers to a minor implementation detail ;-)

Of course, sorry.

Looks like I forgot to attach the updated patch in a previous message. =
Here it is.


--Apple-Mail=_64FD6A78-046E-4E8B-8A46-7F258849914F
Content-Disposition: attachment;
	filename=0001-Add-macOS-sandboxing-bug-45198.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0001-Add-macOS-sandboxing-bug-45198.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=2078906da41140dc33119b419a410c4a4f0a3aee80=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20=
<mattiase@HIDDEN>=0ADate:=20Sat,=2017=20Apr=202021=2020:53:39=20+0200=0A=
Subject:=20[PATCH]=20Add=20macOS=20sandboxing=20(bug#45198)=0A=0AThis=20=
is=20the=20corresponding=20low-level=20sandboxing=20facility=20=
corresponding=0Ato=20the=20recently=20added=20Seccomp=20for=20Linux.=20=20=
`darwin-sandbox-init`=20gives=0Adirect=20access=20to=20the=20system=20=
sandboxing=20call;=20`darwin-sandbox-enter`=20is=0Aa=20wrapper=20that=20=
takes=20a=20list=20of=20directories=20under=20which=20files=20can=20be=0A=
read.=20=20These=20should=20be=20considered=20internal=20mechanisms=20=
for=20now.=0A=0A*=20lisp/subr.el=20(darwin-sandbox-enter):=0A*=20=
src/sysdep.c=20(Fdarwin_sandbox_init):=20New=20functions.=0A*=20=
test/src/emacs-tests.el=20(emacs-tests/darwin-sandbox):=20New=20test.=0A=
---=0A=20lisp/subr.el=20=20=20=20=20=20=20=20=20=20=20=20|=2018=20=
+++++++++++=0A=20src/sysdep.c=20=20=20=20=20=20=20=20=20=20=20=20|=2032=20=
+++++++++++++++++++=0A=20test/src/emacs-tests.el=20|=2070=20=
+++++++++++++++++++++++++++++++++++++++++=0A=203=20files=20changed,=20=
120=20insertions(+)=0A=0Adiff=20--git=20a/lisp/subr.el=20b/lisp/subr.el=0A=
index=20c2be26a15f..196512c0c6=20100644=0A---=20a/lisp/subr.el=0A+++=20=
b/lisp/subr.el=0A@@=20-6262,4=20+6262,22=20@@=20=
internal--format-docstring-line=0A=20This=20is=20intended=20for=20=
internal=20use=20only."=0A=20=20=20(internal--fill-string-single-line=20=
(apply=20#'format=20string=20objects)))=0A=20=0A+(when=20(eq=20=
system-type=20'darwin)=0A+=20=20(defun=20darwin-sandbox-enter=20(dirs)=0A=
+=20=20=20=20"Enter=20a=20sandbox=20only=20permitting=20reading=20files=20=
under=20DIRS.=0A+DIRS=20is=20a=20list=20of=20directory=20names.=20=20=
Most=20other=20operations=20such=20as=0A+writing=20files=20and=20network=20=
access=20are=20disallowed.=0A+Existing=20open=20descriptors=20can=20=
still=20be=20used=20freely.=0A+=0A+This=20is=20not=20a=20supported=20=
interface=20and=20is=20for=20internal=20use=20only."=0A+=20=20=20=20=
(darwin-sandbox-init=0A+=20=20=20=20=20(concat=20"(version=201)\n"=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20"(deny=20default)\n"=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20;;=20Emacs=20seems=20to=20need=20/dev/null;=20=
allowing=20it=20does=20no=20harm.=0A+=20=20=20=20=20=20=20=20=20=20=20=20=
=20"(allow=20file-read*=20(path=20\"/dev/null\"))\n"=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20(mapconcat=20(lambda=20(dir)=0A+=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(format=20=
"(allow=20file-read*=20(subpath=20%S))\n"=20dir))=0A+=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20dirs=20""))))=0A+=20=20=
)=0A+=0A=20;;;=20subr.el=20ends=20here=0Adiff=20--git=20a/src/sysdep.c=20=
b/src/sysdep.c=0Aindex=20d940acc4e0..44e8b82bc6=20100644=0A---=20=
a/src/sysdep.c=0A+++=20b/src/sysdep.c=0A@@=20-4286,8=20+4286,40=20@@=20=
str_collate=20(Lisp_Object=20s1,=20Lisp_Object=20s2,=0A=20}=0A=20#endif=09=
/*=20WINDOWSNT=20*/=0A=20=0A+#ifdef=20DARWIN_OS=0A+=0A+/*=20This=20=
function=20prototype=20is=20not=20in=20the=20platform=20header=20files.=0A=
+=20=20=20See=20=
https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0=
.pdf=0A+=20=20=20and=20=
https://chromium.googlesource.com/chromium/src/+/master/sandbox/mac/seatbe=
lt_sandbox_design.md=20*/=0A+int=20sandbox_init_with_parameters(const=20=
char=20*profile,=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20uint64_t=20flags,=0A+=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20const=20char=20*const=20parameters[],=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20char=20**errorbuf);=0A+=0A+DEFUN=20("darwin-sandbox-init",=20=
Fdarwin_sandbox_init,=20Sdarwin_sandbox_init,=0A+=20=20=20=20=20=20=201,=20=
1,=200,=0A+=20=20=20=20=20=20=20doc:=20/*=20Enter=20a=20sandbox=20whose=20=
permitted=20access=20is=20curtailed=20by=20PROFILE.=0A+Already=20open=20=
descriptors=20can=20be=20used=20freely.=0A+PROFILE=20is=20a=20string=20=
in=20the=20macOS=20sandbox=20profile=20language,=0A+a=20set=20of=20rules=20=
in=20a=20Lisp-like=20syntax.=0A+=0A+This=20is=20not=20a=20supported=20=
interface=20and=20is=20for=20internal=20use=20only.=20*/)=0A+=20=20=
(Lisp_Object=20profile)=0A+{=0A+=20=20CHECK_STRING=20(profile);=0A+=20=20=
char=20*err=20=3D=20NULL;=0A+=20=20if=20(sandbox_init_with_parameters=20=
(SSDATA=20(profile),=200,=20NULL,=20&err)=20!=3D=200)=0A+=20=20=20=20=
error=20("sandbox=20error:=20%s",=20err);=0A+=20=20return=20Qnil;=0A+}=0A=
+=0A+#endif=09/*=20DARWIN_OS=20*/=0A+=0A=20void=0A=20syms_of_sysdep=20=
(void)=0A=20{=0A=20=20=20defsubr=20(&Sget_internal_run_time);=0A+#ifdef=20=
DARWIN_OS=0A+=20=20defsubr=20(&Sdarwin_sandbox_init);=0A+#endif=0A=20}=0A=
diff=20--git=20a/test/src/emacs-tests.el=20b/test/src/emacs-tests.el=0A=
index=2009f9a248ef..c1a741c359=20100644=0A---=20=
a/test/src/emacs-tests.el=0A+++=20b/test/src/emacs-tests.el=0A@@=20=
-210,4=20+210,74=20@@=20emacs-tests/bwrap/allows-stdout=0A=20=20=20=20=20=
=20=20=20=20=20=20(should=20(eql=20status=200)))=0A=20=20=20=20=20=20=20=20=
=20(should=20(equal=20(string-trim=20(buffer-string))=20"Hi"))))))=0A=20=0A=
+(defun=20emacs-tests--darwin-run-sandboxed-emacs=20(sandbox-dirs=20=
body)=0A+=20=20"Run=20Emacs=20and=20evaluate=20BODY,=20only=20allowing=20=
reads=20from=20SANDBOX-DIRS.=0A+If=20SANDBOX-DIRS=20is=20`no-sandbox',=20=
then=20run=20without=20sandbox.=0A+Return=20(EXIT-STATUS=20.=20OUTPUT),=20=
where=20OUTPUT=20is=20stderr=20and=20stdout."=0A+=20=20(let=20((emacs=20=
(expand-file-name=20invocation-name=20invocation-directory))=0A+=20=20=20=
=20=20=20=20=20(process-environment=20nil))=0A+=20=20=20=20=
(with-temp-buffer=0A+=20=20=20=20=20=20(let*=20((prog=20`(progn=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20,@(and=20=
(not=20(eq=20sandbox-dirs=20'no-sandbox))=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
`((darwin-sandbox-enter=20',sandbox-dirs)))=0A+=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20,@body))=0A+=20=20=20=20=20=20=20=20=
=20=20=20=20=20(res=20(call-process=20emacs=20nil=20t=20nil=0A+=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20"--quick"=20"--batch"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(format=20=
"--eval=3D%S"=20prog))))=0A+=20=20=20=20=20=20=20=20(cons=20res=20=
(buffer-string))))))=0A+=0A+(ert-deftest=20emacs-tests/darwin-sandbox=20=
()=0A+=20=20(skip-unless=20(eq=20system-type=20'darwin))=0A+=20=20=
(emacs-tests--with-temp-file=20test-file=20("test")=0A+=20=20=20=20(let=20=
((some-text=20"abcdef")=0A+=20=20=20=20=20=20=20=20=20=20(other-text=20=
"ghijkl")=0A+=20=20=20=20=20=20=20=20=20=20(test-file=20(file-truename=20=
test-file)))=20=20=20;=20resolve=20symlinks=0A+=20=20=20=20=20=20=
(with-temp-buffer=0A+=20=20=20=20=20=20=20=20(insert=20some-text)=0A+=20=20=
=20=20=20=20=20=20(write-file=20test-file))=0A+=0A+=20=20=20=20=20=20;;=20=
Read=20the=20file=20without=20allowing=20its=20directory=20--=20should=20=
fail.=0A+=20=20=20=20=20=20(let=20((res-out=20=
(emacs-tests--darwin-run-sandboxed-emacs=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20nil=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20`((find-file-literally=20,test-file)=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(message=20"OK:=20%s"=20(buffer-string))))))=0A+=20=20=20=20=20=20=20=20=
(ert-info=20((cdr=20res-out)=20:prefix=20"output:=20")=0A+=20=20=20=20=20=
=20=20=20=20=20(should-not=20(equal=20(car=20res-out)=200))=0A+=20=20=20=20=
=20=20=20=20=20=20(should-not=20(string-search=20some-text=20(cdr=20=
res-out)))))=0A+=0A+=20=20=20=20=20=20;;=20Read=20the=20file=20allowing=20=
its=20directory=20--=20should=20succeed.=0A+=20=20=20=20=20=20(let=20=
((res-out=20(emacs-tests--darwin-run-sandboxed-emacs=0A+=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(list=20=
(file-name-directory=20test-file))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20`((find-file-literally=20,test-file)=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(message=20"OK:=20%s"=20(buffer-string))))))=0A+=20=20=20=20=20=20=20=20=
(should=20(equal=20res-out=20(cons=200=20(format=20"OK:=20%s\n"=20=
some-text)))))=0A+=0A+=20=20=20=20=20=20;;=20Write=20to=20the=20file=20=
allowing=20directory=20reads=20--=20should=20fail.=0A+=20=20=20=20=20=20=
(let=20((res-out=20(emacs-tests--darwin-run-sandboxed-emacs=0A+=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(list=20=
(file-name-directory=20test-file))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20`((with-temp-buffer=0A+=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(insert=20=
,other-text)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20(write-file=20,test-file))))))=0A+=20=20=20=20=20=20=
=20=20(ert-info=20((cdr=20res-out)=20:prefix=20"output:=20")=0A+=20=20=20=
=20=20=20=20=20=20=20(should-not=20(equal=20(car=20res-out)=200))=0A+=20=20=
=20=20=20=20=20=20=20=20;;=20The=20file=20should=20be=20unchanged.=0A+=20=
=20=20=20=20=20=20=20=20=20(let=20((contents=20(with-temp-buffer=0A+=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20(insert-file-contents-literally=20test-file)=0A+=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(buffer-string))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20(should=20=
(equal=20contents=20some-text)))))=0A+=0A+=20=20=20=20=20=20;;=20Write=20=
to=20the=20file=20without=20sandbox=20--=20should=20succeed.=0A+=20=20=20=
=20=20=20(let=20((res-out=20(emacs-tests--darwin-run-sandboxed-emacs=0A+=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'no-sandbox=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20`((with-temp-buffer=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20(insert=20,other-text)=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(write-file=20,test-file))))))=0A+=20=20=20=20=20=20=20=20(ert-info=20=
((cdr=20res-out)=20:prefix=20"output:=20")=0A+=20=20=20=20=20=20=20=20=20=
=20(should=20(equal=20(car=20res-out)=200))=0A+=20=20=20=20=20=20=20=20=20=
=20;;=20The=20file=20should=20be=20changed.=0A+=20=20=20=20=20=20=20=20=20=
=20(let=20((contents=20(with-temp-buffer=0A+=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(insert-file-contents-literally=20test-file)=0A+=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
(buffer-string))))=0A+=20=20=20=20=20=20=20=20=20=20=20=20(should=20=
(equal=20contents=20other-text))))))))=0A+=0A=20;;;=20emacs-tests.el=20=
ends=20here=0A--=20=0A2.21.1=20(Apple=20Git-122.3)=0A=0A=

--Apple-Mail=_64FD6A78-046E-4E8B-8A46-7F258849914F--

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 18:47:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 14:47:45 2021
Received: from localhost ([127.0.0.1]:44565 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXpyr-00063c-9M
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:47:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57329)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lXpyp-00060v-Bh
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:47:43 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D08EC100222;
 Sat, 17 Apr 2021 14:47:37 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 21F061000C9;
 Sat, 17 Apr 2021 14:47:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618685256;
 bh=jdBJQySwB7QTSpjeo7wNh94YkHClfEfNRAdydUfGZ4w=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=VPbLsG3akHi2l1m57MT9JogxKrbxPaQljfizDoNahgHV0qP88LulwqEh5cO/5gPvi
 HIMUzUWehQ93XJobh6VAdPQ/CMyRdUeYJr2YRXyekCBndHcCK1+lk73vr2w8diSTzv
 TVHl+glho6JNHIaKYwzB7vF4Rn3PlFcLtf1V52wh51Al3y/HGdVMdX3hWX2mz1ge7v
 ZUewQKc9gCNxFQPKmL42DqE07AJv70hypLzH9Rw2C2AfIegBl3y/ma2XlZGBAEGIoL
 yRZXEg+9JkWruANLgkkdSFVh3tmkkc9ChZegYd7BNwiZEAKvqinfppqfhrS64ncrPC
 wmdnqZtCdOmHg==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CC4671201B3;
 Sat, 17 Apr 2021 14:47:35 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwv7dl069cy.fsf-monnier+emacs@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <jwva6pwalxc.fsf-monnier+emacs@HIDDEN> <83o8ecvnok.fsf@HIDDEN>
 <jwv5z0k7qeg.fsf-monnier+emacs@HIDDEN> <83lf9gvktv.fsf@HIDDEN>
Date: Sat, 17 Apr 2021 14:47:34 -0400
In-Reply-To: <83lf9gvktv.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 17 Apr
 2021 21:15:40 +0300")
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.021 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: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 p.stephani2@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 (---)

>> Normally, this untrusted ELisp code (the one present within
>> `eval-when-compile` and macros defined within the file) limits itself to
>> quite simple sexp manipulation, so the sandboxing can be quite
>> restrictive, disallowing things like user interaction, uses of
>> subprocesses, or writing to files.
> How is this different from byte-compiling some code, e.g. one
> downloaded from some elpa?

The normal way to enable flymake is something like

    (add-hook 'emacs-lisp-mode #'flymake-mode)

so the file gets compiled just because you're looking at it.
That's quite different from an explicit request from the user to compile
a file.


        Stefan

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 18:21:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 14:21:35 2021
Received: from localhost ([127.0.0.1]:44523 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXpZX-0001A3-FH
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:21:35 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47125)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lXpZW-00019o-Nf
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:21:35 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 633C9440A28;
 Sat, 17 Apr 2021 14:21:29 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 16819440826;
 Sat, 17 Apr 2021 14:21:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618683688;
 bh=R53Ikd8hsBi/HTFdnoND971Bh4SPf2QO8zOMVN649qc=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=GnxfZi5+vjCu5+NbHJ9k1deeaxPGSzLR2Z3JZ8Pdddlfkr2Aj6t5zjwiU0J1Cuyno
 O7LLCyEsb4lJuzZQCQiHazBDt6gJmicmYd+mNBkD0HkG4P6YRS/bHa++otVpdIgQA9
 enWMTjR9miqeUzFat8RF1LjzytkyXlDL56x58okn2ZRGlTTpofIN70fXXg2N3Qc2+s
 CK7rsTZ4oX7Bo7YThkoa7UVqvKMfI9hKtm+Dy6LbYb52e/6uLiTf/ZgM005V3J+LZe
 bkj/MNfQR9Xa+hDcWINPgdLH3al5Kxotlab/gP0pgAWkwNCywdLp0JqyUZ9XW+sEgy
 PgnAHvCfJpO0g==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A660C1201E0;
 Sat, 17 Apr 2021 14:21:27 -0400 (EDT)
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: <jwvim4k6ade.fsf-monnier+emacs@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN>
Date: Sat, 17 Apr 2021 14:21:25 -0400
In-Reply-To: <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN> ("Mattias
 =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Sat, 17 Apr 2021 19:48:15
 +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.104 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: alan@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 Philipp <p.stephani2@HIDDEN>, joaotavora@HIDDEN,
 Eli Zaretskii <eliz@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 (---)

>> My primary target is `elisp-flymake--batch-compile-for-flymake`.
> Very reasonable. Or would you prefer having the sandboxing in flymake?

AFAICT this question refers to a minor implementation detail ;-)


        Stefan

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 18:16:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 14:16:08 2021
Received: from localhost ([127.0.0.1]:44513 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXpUC-00011i-DZ
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:16:08 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41938)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lXpUA-000117-4R
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:16:02 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:37956)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lXpU3-0006nx-GT; Sat, 17 Apr 2021 14:15:55 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2547
 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 1lXpU2-0005EH-FX; Sat, 17 Apr 2021 14:15:55 -0400
Date: Sat, 17 Apr 2021 21:15:40 +0300
Message-Id: <83lf9gvktv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwv5z0k7qeg.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 17 Apr 2021 13:53:34 -0400)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <jwva6pwalxc.fsf-monnier+emacs@HIDDEN> <83o8ecvnok.fsf@HIDDEN>
 <jwv5z0k7qeg.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 p.stephani2@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: -1.7 (-)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: mattiase@HIDDEN,  joaotavora@HIDDEN,  p.stephani2@HIDDEN,
>   stefan@HIDDEN,  45198 <at> debbugs.gnu.org,  alan@HIDDEN
> Date: Sat, 17 Apr 2021 13:53:34 -0400
> 
> >> My primary target is `elisp-flymake--batch-compile-for-flymake`.
> > What does that mean in practice? what does that "target" require?
> 
> It needs to take untrusted ELisp code and run it (with no need for user
> interaction) in a way that doesn't introduce any security risk.

That's too general to allow any meaningful discussion, in particular
whether seccomp could be the basis for satisfying those requirements.

> Currently the code starts a new Emacs process in batch mode and lets it
> do whatever it wants, with all the security problems this entails.
> 
> Normally, this untrusted ELisp code (the one present within
> `eval-when-compile` and macros defined within the file) limits itself to
> quite simple sexp manipulation, so the sandboxing can be quite
> restrictive, disallowing things like user interaction, uses of
> subprocesses, or writing to files.

How is this different from byte-compiling some code, e.g. one
downloaded from some elpa?

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 17:57:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 13:57:48 2021
Received: from localhost ([127.0.0.1]:44491 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXpCW-0000ZO-Mk
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:57:48 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42414)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lXpCV-0000ZB-03
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:57:47 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9BA49100222;
 Sat, 17 Apr 2021 13:57:41 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1C12C1000C9;
 Sat, 17 Apr 2021 13:57:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618682260;
 bh=5Vht8iW61t/XVw3ACaOZgsJIOUe8uLMwR1KMNkG/wj0=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=iwmls/jkoBCn5oAi1l3bMzWFbjjPpLQZv0+6Gm99WG7poEJiMPIMG0YLE/T4U41/7
 skLeLOzGizXbzHqj4r1UUC+83L4jR2a5dNJ6O/NB2AkLZbZcTZPZ0WK6a/olgO8Djx
 57+devI6p8zw9/6k0wM4UzPNLmskVd85z4J8gObi3McEpAMypQeQgFqRrx+EVdVpEV
 qsyAJJo7KprZK0a1bv9zXUpmEySwMjZZEntYjycuelN0/iGaqvW16CqkdAu2CLzRlG
 8p2gHh68eWVJ4tnuJ+ikfsNqFi+oW+Sj1qyuhB31EFOePo9Rvb61/chsCnG0cKBh9P
 QYYAK2QbRhYgA==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C8D28120191;
 Sat, 17 Apr 2021 13:57:39 -0400 (EDT)
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: <jwvzgxw6bl8.fsf-monnier+emacs@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <077448DE-3E4E-4821-8F5C-5CA62BF217E5@HIDDEN>
Date: Sat, 17 Apr 2021 13:57:38 -0400
In-Reply-To: <077448DE-3E4E-4821-8F5C-5CA62BF217E5@HIDDEN> ("Mattias
 =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Sat, 17 Apr 2021 19:22:31
 +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.021 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: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
 Philipp <p.stephani2@HIDDEN>, Stefan Kangas <stefan@HIDDEN>,
 45198 <at> debbugs.gnu.org, Alan Third <alan@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 (---)

>> As we gain more experience with these sandboxing mechanisms, we can look
>> at relaxing these restrictions, but I think initially we should
>> be conservative.
>
> I take the opposite view, but our goals are the same and we will converge.

I guess the conversion goes like:
- define "low-level" interfaces to OS-specific functionality.  They can
  be as close to the OS's own featureset as we want.  They don't
  really need to be stable over time (especially not at the beginning).
- define an OS-agnostic API on top of them.  This one needs to be
  conservative and should evolve more slowly, paying attention to
  backward compatibility.


        Stefan

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 17:53:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 13:53:49 2021
Received: from localhost ([127.0.0.1]:44486 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXp8f-0000Tn-43
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:53:49 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42079)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lXp8d-0000TZ-Su
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:53:48 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5B96A8055F;
 Sat, 17 Apr 2021 13:53:42 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0594180618;
 Sat, 17 Apr 2021 13:53:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618682016;
 bh=9WyRzCLhEI1zlQ7Ku+iNw8LKU4ud/tAHF3skqW6QqtA=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=X/mL8GELE0zUuPDC0I8OG81Ap+tT7rNcXaWd344KuT7ACTjPnQ18LhkxeZ/SD7uMT
 GxLiMHBzGC8vJujILWGJKYlOti4KrLHKkZ7P1rPnXw1jUtlE8eX+W69j53jEG5G4qX
 cQhjWIIDmrLXsObDLPZGVBeVXbW0Em3hyPRDY9E2GWF78nlFmdOVkHaxj03VOr66W8
 bgxlXq8ejZn3iNfzMY774QsE8QM6G5sBeeGl4o3GjmjI2TvT4pGuHAlg6YZdKG3lik
 k2ggWaDwU4V1YfKBbL+uuZsM37F3P0Tq0gl2W8fJd8NiaHWdXYqJHLrRhoY/WpRFBl
 Q9MYcrL1L7dlw==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B0A881202BB;
 Sat, 17 Apr 2021 13:53:35 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwv5z0k7qeg.fsf-monnier+emacs@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <jwva6pwalxc.fsf-monnier+emacs@HIDDEN> <83o8ecvnok.fsf@HIDDEN>
Date: Sat, 17 Apr 2021 13:53:34 -0400
In-Reply-To: <83o8ecvnok.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 17 Apr
 2021 20:14:03 +0300")
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.055 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: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 p.stephani2@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 (---)

>> My primary target is `elisp-flymake--batch-compile-for-flymake`.
> What does that mean in practice? what does that "target" require?

It needs to take untrusted ELisp code and run it (with no need for user
interaction) in a way that doesn't introduce any security risk.

Currently the code starts a new Emacs process in batch mode and lets it
do whatever it wants, with all the security problems this entails.

Normally, this untrusted ELisp code (the one present within
`eval-when-compile` and macros defined within the file) limits itself to
quite simple sexp manipulation, so the sandboxing can be quite
restrictive, disallowing things like user interaction, uses of
subprocesses, or writing to files.


        Stefan

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 17:48:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 13:48:29 2021
Received: from localhost ([127.0.0.1]:44481 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXp3V-0000MC-DA
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:48:29 -0400
Received: from mail1453c50.megamailservers.eu ([91.136.14.53]:47718
 helo=mail266c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1lXp3T-0000Ly-5n
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:48:28 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1618681700;
 bh=JOxJo2KpqX+hhHcUZF7wdaRGumt0FZF0b/QSvM3dS/w=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=CgKNV4kASVqLaW3CphyD/kyphjSadoOiXIpajL0CPTvpP8Ehc3+ZHnrdQyWXUt5Ji
 q44y33vbSnrlJl5glDX80sXtFc3NbeZr7DM0PFZ20YlAa/QrpVTfLAo1IMxmEvBQ9Z
 isY8enk8OPO2RKJoWPc5NJGdOI02ge7eq00vNzfo=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-b952e353.032-75-73746f71.bbcust.telenor.se
 [83.227.82.185]) (authenticated bits=0)
 by mail266c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 13HHmFJ9024388; 
 Sat, 17 Apr 2021 17:48:16 +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: <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
Date: Sat, 17 Apr 2021 19:48:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AAAE6F07-7424-4632-B2DB-528649DB412A@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
To: Philipp <p.stephani2@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A742F20.607B1F64.001A, 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=VISjYOHX c=1 sm=1 tr=0 a=von4qPfY+hyqc0zmWf0tYQ==:117
 a=von4qPfY+hyqc0zmWf0tYQ==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=pGLkceISAAAA:8 a=iRZporoAAAAA:8 a=pmwR3f5yY_1N4VuMQTwA:9
 a=CjuIK1q_8ugA:10 a=NOBgFS-JBQ2l-kSd6-zu:22
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: 17 apr. 2021 kl. 18.10 skrev Philipp <p.stephani2@HIDDEN>:
 > (cl-defun start-sandbox (function &key readable-directories stdout-buffer)
 ...) > (defun wait-for-sandbox (sandbox) ...) > > where start-sandbox returns
 an opaque sandbox object running FUNCTION tha [...] 
 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: alan@HIDDEN, 45198 <at> debbugs.gnu.org, stefankangas@HIDDEN,
 joaotavora@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 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: -0.0 (/)

17 apr. 2021 kl. 18.10 skrev Philipp <p.stephani2@HIDDEN>:

> (cl-defun start-sandbox (function &key readable-directories =
stdout-buffer) ...)
> (defun wait-for-sandbox (sandbox) ...)
>=20
> where start-sandbox returns an opaque sandbox object running FUNCTION =
that wait-for-sandbox can wait for.  That should be generic enough that =
it's extensible and implementable on several platforms, and doesn't lock =
us into specific implementation choices.

That's probably a nice interface. A slightly more low-level mechanism is =
what I had in mind, a `make-process` variant that starts an Emacs =
subprocess with the required arguments to set up a sandbox and leaving =
it to the user to supply remaining arguments. But maybe we are really =
talking about more or less the same thing.


17 apr. 2021 kl. 18.58 skrev Stefan Monnier <monnier@HIDDEN>:

> My primary target is `elisp-flymake--batch-compile-for-flymake`.

Very reasonable. Or would you prefer having the sandboxing in flymake?

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 17:22:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 13:22:40 2021
Received: from localhost ([127.0.0.1]:44438 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXoeV-00061f-UW
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:22:40 -0400
Received: from mail203c50.megamailservers.eu ([91.136.10.213]:58476
 helo=mail193c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1lXoeS-00061W-VC
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:22:38 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1618680155;
 bh=Yda9rMhayL6bAwl+6URONmhJ3B3N+xfmY9YsgJ+8rVQ=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
 b=LJAQGz5o+BFq/daR8DEe1wJxg9J3fNsxyyaP6BP0nx+6QAQiFQX5PLyRSqMQcKomd
 GfAi1zDP1QyYOD0HgSgy28JEq05Sa7FRrbOwficFI6POHB1OoWF/VhgnRCFzVSSr4H
 sT2t96eToPUEMA8leYtiSEBHbJZtgFHA79FeL9dA=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-b952e353.032-75-73746f71.bbcust.telenor.se
 [83.227.82.185]) (authenticated bits=0)
 by mail193c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 13HHMW0R023013; 
 Sat, 17 Apr 2021 17:22:33 +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: <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
Date: Sat, 17 Apr 2021 19:22:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <077448DE-3E4E-4821-8F5C-5CA62BF217E5@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
To: Philipp <p.stephani2@HIDDEN>
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A742F17.607B195B.001E, 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=PqLtkDE3 c=1 sm=1 tr=0 a=von4qPfY+hyqc0zmWf0tYQ==:117
 a=von4qPfY+hyqc0zmWf0tYQ==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10
 a=pGLkceISAAAA:8 a=x48ymFGV-5Z2z8zwfxgA:9 a=CjuIK1q_8ugA:10
X-Origin-Country: SE
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 45198
Cc: 45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>,
 Alan Third <alan@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.0 (/)

17 apr. 2021 kl. 17.44 skrev Philipp <p.stephani2@HIDDEN>:

> I think it would be better to first implement the mechanism and not =
the high-level `sandbox-enter' function

Sorry, there's a misunderstanding here -- it's just a name (and not =
meant to be a high-level function). I've given it a more =
platform-specific name. It is not meant to be a general interface to =
which any thing else has to conform.

Whether it should use --darwin-sandbox instead of --eval =
"(darwin-sandbox '(\"DIR\"))" is not very important at this point. It's =
not intended for general use in any case (and the doc strings now make =
this clear).

In particular, we do not benefit from artificially restricting the macOS =
sandboxing until we know what is needed. Nothing like a Lisp interface =
for experimentation!

> As we gain more experience with these sandboxing mechanisms, we can =
look at relaxing these restrictions, but I think initially we should be =
conservative.

I take the opposite view, but our goals are the same and we will =
converge.

> Is there any documentation you could refer to, even only an unofficial =
one?

Well, I dug up some web links that will be gone tomorrow...

> This needs to somehow document what PROFILE is.

You are right; elaborated.

>> +Already open descriptors can be used freely. */)
>=20
> What does this mean?  Emacs doesn't really expose file descriptors to =
users.

It sort of does (in the form of processes), but there could also be =
descriptors not directly exposed. It would be incomplete not to mention =
the possibility. It looks like the seccomp filter generator uses the =
same policy, treating descriptors as capabilities.

> Missing CHECK_STRING (profile).

Thanks! Fixed.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 17:14:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 13:14:30 2021
Received: from localhost ([127.0.0.1]:44430 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXoWb-0005pO-Op
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:14:29 -0400
Received: from eggs.gnu.org ([209.51.188.92]:54650)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lXoWa-0005pC-5M
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 13:14:28 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36995)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lXoWT-0004dT-OV; Sat, 17 Apr 2021 13:14:21 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2768
 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 1lXoWN-00036e-4Q; Sat, 17 Apr 2021 13:14:16 -0400
Date: Sat, 17 Apr 2021 20:14:03 +0300
Message-Id: <83o8ecvnok.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwva6pwalxc.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 17 Apr 2021 12:58:55 -0400)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <jwva6pwalxc.fsf-monnier+emacs@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org, stefan@HIDDEN,
 p.stephani2@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: -1.7 (-)

> From: Stefan Monnier <monnier@HIDDEN>
> Date: Sat, 17 Apr 2021 12:58:55 -0400
> Cc: João Távora <joaotavora@HIDDEN>,
>  Philipp Stephani <p.stephani2@HIDDEN>, Stefan Kangas <stefan@HIDDEN>,
>  45198 <at> debbugs.gnu.org, Alan Third <alan@HIDDEN>
> 
> My primary target is `elisp-flymake--batch-compile-for-flymake`.

What does that mean in practice? what does that "target" require?

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 16:59:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 12:59:06 2021
Received: from localhost ([127.0.0.1]:44255 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXoHh-0005G4-Kx
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:59:05 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17908)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lXoHf-0005FT-IG
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:59:04 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0373880967;
 Sat, 17 Apr 2021 12:58:58 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8EE3380618;
 Sat, 17 Apr 2021 12:58:56 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618678736;
 bh=hFTscQdOm/n6O+KV9REJfD2Tp+FjpnZoux5UzQ7MocQ=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=KrGs5j0Rq8F1EcRT9vWEpO45A2Hm6vYpNjprhvPmJpYOT4GK6qMe+sdgJdjJ2uYXt
 FECZYTTgddE525q8Z6mOTsGdNijH7savyfSDcJvsCNPFR5/rSI8nNb2l894h0HgrtR
 adCwefiIG+EADtbi8W7O2Ca6NMEp1QjB270nA20XkIHTqGWzDuMEhZkW+xhZtJviDC
 iSXjnAWVl0iqjambNY86WtAg0JITeiDwvKwRDZ5IH3lSNVQU8+ztGMTTVvQUpjzk2Q
 OyIrtYig6oC06HQRNDi6BHFTbpomdocozj4pzTjCyBvDpPBKQo+vKQG5XTLaOTAHkK
 hwBtvqsMACqaA==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 498A012027B;
 Sat, 17 Apr 2021 12:58:56 -0400 (EDT)
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: <jwva6pwalxc.fsf-monnier+emacs@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
Date: Sat, 17 Apr 2021 12:58:55 -0400
In-Reply-To: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN> ("Mattias
 =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Sat, 17 Apr 2021 17:26:03
 +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.055 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: Philipp Stephani <p.stephani2@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefan@HIDDEN>, Alan Third <alan@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 works and can be pushed right away but it would be nice to have a place
> to use it, for validation and for tuning the interface. Any plans for that?

My primary target is `elisp-flymake--batch-compile-for-flymake`.


        Stefan

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 16:33:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 12:33:29 2021
Received: from localhost ([127.0.0.1]:44234 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXnsv-0004fm-AI
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:33:29 -0400
Received: from eggs.gnu.org ([209.51.188.92]:43052)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lXnsu-0004fb-F1
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:33:28 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36226)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lXnso-00023D-Do; Sat, 17 Apr 2021 12:33:22 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4186
 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 1lXnsk-0000zr-7w; Sat, 17 Apr 2021 12:33:21 -0400
Date: Sat, 17 Apr 2021 19:33:05 +0300
Message-Id: <83r1j8vpku.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <CAArVCkQq5Zrdk31wdoDmTSqbEc+aPHdLy8w9ZuZmzQ2t83NSjw@HIDDEN>
 (message from Philipp Stephani on Sat, 17 Apr 2021 18:20:15 +0200)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <83v98kvr7y.fsf@HIDDEN> <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <83tuo4vqet.fsf@HIDDEN>
 <CAArVCkQq5Zrdk31wdoDmTSqbEc+aPHdLy8w9ZuZmzQ2t83NSjw@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org,
 stefankangas@HIDDEN, joaotavora@HIDDEN, 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.7 (-)

> From: Philipp Stephani <p.stephani2@HIDDEN>
> Date: Sat, 17 Apr 2021 18:20:15 +0200
> Cc: Mattias Engdegård <mattiase@HIDDEN>, 
> 	João Távora <joaotavora@HIDDEN>, 
> 	45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>, 
> 	Stefan Monnier <monnier@HIDDEN>, Alan Third <alan@HIDDEN>
> 
> That's a fair statement, and I'll try to answer here (and hopefully
> later in the other thread as well). The sandbox should be able to
> perform operations that are in some sense not security-relevant:
> mostly performing computations, reading some necessary files, and
> writing some diagnostics to standard output. The initial use case can
> be running byte compilation in a Flymake backend. This would allow us
> to enable Flymake byte compilation support by default, even on
> untrusted code, because due to the sandbox that code could never
> perform harmful operations. The Flymake backend would then use the
> high-level sandbox functions to asynchronously start byte compilation
> in a sandbox. The start-sandbox function in turn would launch an Emacs
> subprocess using bwrap or similar to set up appropriate mount
> namespaces and apply a Seccomp filter (in the GNU/Linux case).

Thanks.  I think I understand the general idea, but not how to
translate that into real life.

"Performing computations" in Emacs corresponds to invoking gobs of
system interfaces, and if we are going to filter most of them, I fear
we will get a dysfunctional Emacs.  E.g., cursor blinking requires
accessing the system time, displaying a busy cursor requires interval
timers, profiling requires signals, and you cannot do anything in
Emacs without being able to allocate memory.  If we leave Emacs only
with capabilities to read and write to a couple of descriptors, how
will the result be useful?  Even if Flymake byte compilation can live
in such a sandbox (and I'm not yet certain it can), is that the most
important situation where untrusted code could be run by Emacs?

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 16:20:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 12:20:35 2021
Received: from localhost ([127.0.0.1]:44225 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXngQ-0004MV-Ls
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:20:34 -0400
Received: from mail-oo1-f43.google.com ([209.85.161.43]:35750)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lXngO-0004MI-AN
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:20:33 -0400
Received: by mail-oo1-f43.google.com with SMTP id
 i20-20020a4a8d940000b02901bc71746525so6804618ook.2
 for <45198 <at> debbugs.gnu.org>; Sat, 17 Apr 2021 09:20:32 -0700 (PDT)
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=95ERRKeJdZdRu4SQoVtuuzPA+A10dOVHsIlSu813uNQ=;
 b=Br1f1q3mEt0qPl8+bvfxJD+HcYtVkpyQXFOwEc36Nqu6eB2LHg/Brw1Kr0RCViUw1g
 ztn2zAyiN5RffpNAUntb4w7eXZi3eUHXZdr4s/mUy3vx49w7wrdBpNyb0qy6lrVmDr22
 Kjiap1kOR0gjnSMYxRCzfun3WoqdLtoQhyefZbaTLHK1lspc4UZItN0iL7s4LDBDU7VB
 hoGeH0GLeAMwEjWBEpJisnmynIsARf4xUGO37+P/9rWWXOuwe6gRX37DJP2smR1A4TvF
 vIJuBCowubU2zs/Och94OMY2EekLQOgIrgQiy3TXShcIcXfxXKGmWNLYN0KcbM+yK4hb
 DJcg==
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=95ERRKeJdZdRu4SQoVtuuzPA+A10dOVHsIlSu813uNQ=;
 b=JDeFboXXIKB5AAPkpe6NxBKxaiEZ69XTDbhkQkFL5XKgHbaAEvxWDsEDoiXgN3xx3W
 p790xtXI81ujhUKZmEomXCQW/qXIWVB9ZXdM83Ujmxiow0bxEis0P6E2hJWHlCjwjbJJ
 NcuvmlbC8BlU7TCWUKoIiNc9Ezu5NUS2zWRKnzAXJSaHEb5ugzzFGjZO1d2arzcIjx81
 Ll7eiFbTfVk/SjbjeTgg6lgWTmQJMIgd/2+XWWm+wzbsJnTmMX80iLpHhKaBN8OmGynL
 Jotv9EecsX4Ty5YMS0RsToZSy4RnMmt68zhPvETHojmjkDKtjQaZGJCNtComMiylrvDK
 p4RQ==
X-Gm-Message-State: AOAM532uYOO4Eg/CrAeFxhRYdJcXMUHKjLN3JdgWNd5whxxuYqGOVdLx
 Go3U9c7gNbtRCDeYl4+N0BlWN/Q20e1fd8TY6iI=
X-Google-Smtp-Source: ABdhPJwbKsM7xol3fwnphHsNj5Bvs4Fs8pi8p6n+sL3/dAKvLSEdlZh1q12p7dkS34YyfLygkZAKl7aUCf8Ky0/+njA=
X-Received: by 2002:a4a:4f53:: with SMTP id c80mr1396067oob.45.1618676426702; 
 Sat, 17 Apr 2021 09:20:26 -0700 (PDT)
MIME-Version: 1.0
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
 <83v98kvr7y.fsf@HIDDEN> <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
 <83tuo4vqet.fsf@HIDDEN>
In-Reply-To: <83tuo4vqet.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 17 Apr 2021 18:20:15 +0200
Message-ID: <CAArVCkQq5Zrdk31wdoDmTSqbEc+aPHdLy8w9ZuZmzQ2t83NSjw@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.3 (/)
X-Debbugs-Envelope-To: 45198
Cc: Alan Third <alan@HIDDEN>,
 =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>, 45198 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas@HIDDEN>,
 =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@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: -0.7 (/)

Am Sa., 17. Apr. 2021 um 18:15 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
>
> > From: Philipp <p.stephani2@HIDDEN>
> > Date: Sat, 17 Apr 2021 18:10:14 +0200
> > Cc: mattiase@HIDDEN,
> >  joaotavora@HIDDEN,
> >  45198 <at> debbugs.gnu.org,
> >  stefankangas@HIDDEN,
> >  monnier@HIDDEN,
> >  alan@HIDDEN
> >
> > > IMO, if we have no reasonably clear idea how this will be used on the
> > > high level,
> >
> > I have a relatively clear idea how I want the high-level interface to l=
ook like:
> >
> > (cl-defun start-sandbox (function &key readable-directories stdout-buff=
er) ...)
> > (defun wait-for-sandbox (sandbox) ...)
> >
> > where start-sandbox returns an opaque sandbox object running FUNCTION t=
hat wait-for-sandbox can wait for.  That should be generic enough that it's=
 extensible and implementable on several platforms, and doesn't lock us int=
o specific implementation choices.
> >
> > If that's OK with everyone, then I'm happy to write the code for it.
>
> I'm sorry, but I don't really understand what the above means in
> practice.
>
> What I'm missing is some details about what operations (in Emacs
> terms) should not be allowed in the sandbox, and how can users take
> advantage of that.  I asked more questions about this a few days ago,
> but got no responses.  I don't really understand how we can
> intelligently talk about using this in Emacs while we remain on the
> level of file descriptors and syscalls.

That's a fair statement, and I'll try to answer here (and hopefully
later in the other thread as well). The sandbox should be able to
perform operations that are in some sense not security-relevant:
mostly performing computations, reading some necessary files, and
writing some diagnostics to standard output. The initial use case can
be running byte compilation in a Flymake backend. This would allow us
to enable Flymake byte compilation support by default, even on
untrusted code, because due to the sandbox that code could never
perform harmful operations. The Flymake backend would then use the
high-level sandbox functions to asynchronously start byte compilation
in a sandbox. The start-sandbox function in turn would launch an Emacs
subprocess using bwrap or similar to set up appropriate mount
namespaces and apply a Seccomp filter (in the GNU/Linux case).

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 16:19:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 12:19:32 2021
Received: from localhost ([127.0.0.1]:44220 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXnfQ-0004KX-9u
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:19:32 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41302)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lXnfP-0004KL-1Y
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:19:31 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36001)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lXnfH-0004V9-KR; Sat, 17 Apr 2021 12:19:24 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3190
 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 1lXnfB-0004ST-14; Sat, 17 Apr 2021 12:19:21 -0400
Date: Sat, 17 Apr 2021 19:19:07 +0300
Message-Id: <83sg3ovq84.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: p.stephani2@HIDDEN
In-Reply-To: <83tuo4vqet.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 17
 Apr 2021 19:15:06 +0300)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN> <83tuo4vqet.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org,
 stefankangas@HIDDEN, joaotavora@HIDDEN, 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.7 (-)

> Date: Sat, 17 Apr 2021 19:15:06 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org,
>  stefankangas@HIDDEN, joaotavora@HIDDEN, monnier@HIDDEN
> 
> What I'm missing is some details about what operations (in Emacs
> terms) should not be allowed in the sandbox, and how can users take
> advantage of that.  I asked more questions about this a few days ago,
> but got no responses.  I don't really understand how we can
> intelligently talk about using this in Emacs while we remain on the
> level of file descriptors and syscalls.

Btw, please don't interpret the above as pressure to get these issues
discussed and figured out.  There's no pressure; all I'm saying is
that if this is preliminary code for which we don't yet have a clear
common idea about its practical usage, it should be on a branch.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 16:15:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 12:15:30 2021
Received: from localhost ([127.0.0.1]:44207 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXnbW-0004E4-7N
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:15:30 -0400
Received: from eggs.gnu.org ([209.51.188.92]:40864)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lXnbU-0004Dp-8V
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:15:28 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:35935)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lXnbN-0002lg-Ee; Sat, 17 Apr 2021 12:15:22 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2946
 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 1lXnbL-0004Am-H4; Sat, 17 Apr 2021 12:15:20 -0400
Date: Sat, 17 Apr 2021 19:15:06 +0300
Message-Id: <83tuo4vqet.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp <p.stephani2@HIDDEN>
In-Reply-To: <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN> (message from
 Philipp on Sat, 17 Apr 2021 18:10:14 +0200)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
 <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org,
 stefankangas@HIDDEN, joaotavora@HIDDEN, 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.7 (-)

> From: Philipp <p.stephani2@HIDDEN>
> Date: Sat, 17 Apr 2021 18:10:14 +0200
> Cc: mattiase@HIDDEN,
>  joaotavora@HIDDEN,
>  45198 <at> debbugs.gnu.org,
>  stefankangas@HIDDEN,
>  monnier@HIDDEN,
>  alan@HIDDEN
> 
> > IMO, if we have no reasonably clear idea how this will be used on the
> > high level,
> 
> I have a relatively clear idea how I want the high-level interface to look like:
> 
> (cl-defun start-sandbox (function &key readable-directories stdout-buffer) ...)
> (defun wait-for-sandbox (sandbox) ...)
> 
> where start-sandbox returns an opaque sandbox object running FUNCTION that wait-for-sandbox can wait for.  That should be generic enough that it's extensible and implementable on several platforms, and doesn't lock us into specific implementation choices.
> 
> If that's OK with everyone, then I'm happy to write the code for it.

I'm sorry, but I don't really understand what the above means in
practice.

What I'm missing is some details about what operations (in Emacs
terms) should not be allowed in the sandbox, and how can users take
advantage of that.  I asked more questions about this a few days ago,
but got no responses.  I don't really understand how we can
intelligently talk about using this in Emacs while we remain on the
level of file descriptors and syscalls.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 16:10:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 12:10:23 2021
Received: from localhost ([127.0.0.1]:44197 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXnWZ-000467-83
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:10:23 -0400
Received: from mail-ej1-f47.google.com ([209.85.218.47]:33280)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lXnWY-00045r-1j
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:10:22 -0400
Received: by mail-ej1-f47.google.com with SMTP id g5so39776288ejx.0
 for <45198 <at> debbugs.gnu.org>; Sat, 17 Apr 2021 09:10:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=P1ViWqoAyC6pIhsid45kN/g90qsav9nCKWQDtKu4P5g=;
 b=RdKkaPoHVkcaOC+XHyj1dqLFfptghTNJvnKcvtlRTRVIfXklR/cRClA3Bxy3VCU6Zn
 6TS6H9jUM4Ek3GHoagHpJO2t8OKyFJTqitC23fI3pKgySD//nWQROxd/05diepMPLNTw
 Hz1/rEwk72yROVNBGYxGOtyqX2x81d//pdIkGwxpdcoEg9xQS7382YyAbEx5OznlWyw0
 cwqShaT7wTFD8qOUBeQbhmEopXgLL19gk8WmBKzDRvMHAkij6pMoYtrDQR7uDme1H1bR
 mYh6+EsOZdH5It/30sssC7xhIb5EkCEnkB8UfcrumjuUWQ1GjrmiJedhegog1YTfBwFN
 foYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=P1ViWqoAyC6pIhsid45kN/g90qsav9nCKWQDtKu4P5g=;
 b=k/nFR9xmc6lIPg+BZ1M6m8HRpsoEMA4UrH7Ck+OAGm7/WxtfAprJZET6oI2ItWcheJ
 1w5U/ze1Reg2sjlP8u/IjfzK89GQ6w5SZH3oZ3mXJjG8X2bjQvqL1FPVCFbMjuiulD5I
 JWEd2u+7gRv264OOQlEOFeZmQw6Wakz4W6wbyoTYWX+L8r0YrUwxsFMOTuPqp2zXC3w2
 pJedHB1br5OXYulnovsWpn6CPlIy2/7Mugjn1jHvbecIdnJ//48/U7rx3cHP5ukxIckB
 d4tNrELsO3FHg2YsZjOufRYGm0/d4HlKme1IqoCRmcT1Q1p48YtkIEFeYaj1uEESk70L
 P1ag==
X-Gm-Message-State: AOAM531+HNQ4fUoEW55U+IGQ9lUL6TGmxUispx/W2N9qaRmMGn89FnAO
 +cad1v8Tjel9s3hodScaSx8=
X-Google-Smtp-Source: ABdhPJyhzNyOJJgrkob1nfQki3+vm1pN7YwBvXnOcnDej3J0YS03pKPrx+cmRNhUeDlFkXLJadHx5g==
X-Received: by 2002:a17:907:62a7:: with SMTP id
 nd39mr13870441ejc.510.1618675816178; 
 Sat, 17 Apr 2021 09:10:16 -0700 (PDT)
Received: from philipps-macbook-pro.fritz.box (p57aafcaa.dip0.t-ipconnect.de.
 [87.170.252.170])
 by smtp.gmail.com with ESMTPSA id ws15sm6665316ejb.38.2021.04.17.09.10.14
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Sat, 17 Apr 2021 09:10:15 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: Philipp <p.stephani2@HIDDEN>
In-Reply-To: <83v98kvr7y.fsf@HIDDEN>
Date: Sat, 17 Apr 2021 18:10:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A5BCDF3-6543-46C0-AB56-2311392FC549@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> <83v98kvr7y.fsf@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org,
 stefankangas@HIDDEN, joaotavora@HIDDEN, 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: -0.8 (/)



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

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

(cl-defun start-sandbox (function &key readable-directories =
stdout-buffer) ...)
(defun wait-for-sandbox (sandbox) ...)

where start-sandbox returns an opaque sandbox object running FUNCTION =
that wait-for-sandbox can wait for.  That should be generic enough that =
it's extensible and implementable on several platforms, and doesn't lock =
us into specific implementation choices.

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

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 15:57:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 11:57:57 2021
Received: from localhost ([127.0.0.1]:44189 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXnKW-0003nE-NT
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 11:57:56 -0400
Received: from eggs.gnu.org ([209.51.188.92]:38542)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lXnKV-0003n2-7w
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 11:57:55 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:35480)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lXnKO-0002jU-He; Sat, 17 Apr 2021 11:57:48 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1862
 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 1lXnKM-00009G-Jc; Sat, 17 Apr 2021 11:57:48 -0400
Date: Sat, 17 Apr 2021 18:57:37 +0300
Message-Id: <83v98kvr7y.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp <p.stephani2@HIDDEN>
In-Reply-To: <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN> (message from
 Philipp on Sat, 17 Apr 2021 17:44:06 +0200)
Subject: Re: bug#45198: 28.0.50; Sandbox mode
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
 <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: alan@HIDDEN, mattiase@HIDDEN, 45198 <at> debbugs.gnu.org,
 stefankangas@HIDDEN, joaotavora@HIDDEN, 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.7 (-)

> From: Philipp <p.stephani2@HIDDEN>
> Date: Sat, 17 Apr 2021 17:44:06 +0200
> Cc: João Távora <joaotavora@HIDDEN>,
>  45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>,
>  Stefan Monnier <monnier@HIDDEN>, Alan Third <alan@HIDDEN>
> 
> > It works and can be pushed right away but it would be nice to have a place to use it, for validation and for tuning the interface. Any plans for that?
> > 
> 
> I think it would be better to first implement the mechanism and not the high-level `sandbox-enter' function (I think that one needs a bit more discussion), and implement the mechanism as a command-line flag.

IMO, if we have no reasonably clear idea how this will be used on the
high level, it might make sense to move this to a feature branch,
instead of working on master.  That's because without a high-level
view, there's no way people could try implementing the same
functionality on platforms other than GNU/Linux, let alone use it.  So
from my POV, at this point this is just an experiment, and we have
feature branches for that.

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 15:44:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 11:44:17 2021
Received: from localhost ([127.0.0.1]:44178 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXn7I-0003U2-Lj
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 11:44:16 -0400
Received: from mail-ej1-f51.google.com ([209.85.218.51]:38472)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lXn7G-0003To-HZ
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 11:44:15 -0400
Received: by mail-ej1-f51.google.com with SMTP id r12so46446004ejr.5
 for <45198 <at> debbugs.gnu.org>; Sat, 17 Apr 2021 08:44:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=c3Ww/tmyGygJ2uwXpdP8pZrpQCLs04DA9W2NNRdfKuY=;
 b=pyvjne2i6d5nZxrxw8jHves53sGgYKtbcrIfu59zx07AuYvkOVrmUr62aty5Hr06fy
 JDXa0xKL2ZL8Q2WFIhhJOnjf8X72baHL8DTlBjIotqYxeaLHPjOH5NcsbsR+IMqhO8Ps
 thWOcel0wmO1k9mtIM3rYXsydiXszudksLHOjsh+dSLtXbTYAZkFA31QLGUh+zPsp0/W
 +v+BGy3i8FMuRL3mBFn75cPD6NdXb8Y15rwwHXce7QjYjTP2bX9mwDtbij0MzBc+6+Uj
 VD4eBhZKfLmoZRn3Awf3oKnaCR8RVMm0ovJ4unImMpi+5XhA974Uu7323SLFvffWUtFZ
 fdVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=c3Ww/tmyGygJ2uwXpdP8pZrpQCLs04DA9W2NNRdfKuY=;
 b=n4Cl7mFSN7KEsBbqdr52xkeJ3sXzrzuM7qdIVeG/vPNjVI745ZLkJy+EVYOzgkxWG1
 RVaZOOoZ+gT9xAm5Hb4k50sK+pdzNYmE6EzIWXWQ+rvE/KKa+lLTSAj5iv/qbrlrXsRm
 QU5hXSKEbhj9z8n2i81Syx25uuIVqJWoe7hzKlIIPi2O9d7cjFi9ZRnfVn9Sk6wNmAYD
 Nt+R+ZHucyu4I+rDiXV1WBqBgt5FYdcvtdltvLcvVpg1+cWf4Lei+f1J918Uin/Uco0/
 GUyb5iLo1y3W+LAeEbqLtYg/Nrx6u8fX6oJD86t5tbs+7S0O3AcXwQudf9efuKq/OCPg
 8Vkg==
X-Gm-Message-State: AOAM533Rw32m9I9PwKd8BO9F2xgF0wpb71+tNfu3qdQG43tQqsbDIPfk
 2xArah5SvzAt2MPfj4B6tXs=
X-Google-Smtp-Source: ABdhPJzImxuix42EFMXBDjy9Q1imikc4ZWljD/St07SbZgqxSO1UTt78vI6a44JyqWNrTkOueMHKKA==
X-Received: by 2002:a17:906:c30d:: with SMTP id
 s13mr13739882ejz.68.1618674248617; 
 Sat, 17 Apr 2021 08:44:08 -0700 (PDT)
Received: from philipps-macbook-pro.fritz.box (p57aafcaa.dip0.t-ipconnect.de.
 [87.170.252.170])
 by smtp.gmail.com with ESMTPSA id d24sm859759ejd.57.2021.04.17.08.44.07
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Sat, 17 Apr 2021 08:44:08 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
From: Philipp <p.stephani2@HIDDEN>
In-Reply-To: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
Date: Sat, 17 Apr 2021 17:44:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <19511709-E42B-4ABD-9823-39EA08A79B1F@HIDDEN>
References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
To: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 45198
Cc: 45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>,
 Alan Third <alan@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 17.04.2021 um 17:26 schrieb Mattias Engdeg=C3=A5rd =
<mattiase@HIDDEN>:
>=20
> Slightly updated patch for macOS. Obviously not nearly as fancy as the =
seccomp one but for running something in batch mode that reads from =
files and writes to stdout/stderr it should do.
>=20
> It works and can be pushed right away but it would be nice to have a =
place to use it, for validation and for tuning the interface. Any plans =
for that?
>=20

I think it would be better to first implement the mechanism and not the =
high-level `sandbox-enter' function (I think that one needs a bit more =
discussion), and implement the mechanism as a command-line flag.  This =
would not only be consistent with the Seccomp implementation, but also =
be somewhat more conservative in that it wouldn't require the sandboxing =
functionality to work in arbitrary running Emacs processes.  As we gain =
more experience with these sandboxing mechanisms, we can look at =
relaxing these restrictions, but I think initially we should be =
conservative.


> diff --git a/lisp/subr.el b/lisp/subr.el
> index c2be26a15f..4994771c33 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -6262,4 +6262,20 @@ internal--format-docstring-line
>  This is intended for internal use only."
>    (internal--fill-string-single-line (apply #'format string =
objects)))
> =20
> +(when (eq system-type 'darwin)
> +  (defun sandbox-enter (dirs)
> +    "Enter a sandbox only permitting reading files under DIRS.
> +DIRS is a list of directory names.  Most other operations such as
> +writing files and network access are disallowed.
> +Existing open descriptors can still be used freely."
> +    (darwin-sandbox-init
> +     (concat "(version 1)\n"
> +             "(deny default)\n"
> +             ;; Emacs seems to need /dev/null; allowing it does no =
harm.
> +             "(allow file-read* (path \"/dev/null\"))\n"
> +             (mapconcat (lambda (dir)
> +                          (format "(allow file-read* (subpath %S))\n" =
dir))
> +                        dirs ""))))
> +  )
> +
>  ;;; subr.el ends here

I think it would be better to not commit to a high-level interface like =
`sandbox-enter' yet.  I intentionally held off adding such an interface =
in my patch because I think it deserves more discussion about the right =
design and interface.

> diff --git a/src/sysdep.c b/src/sysdep.c
> index d940acc4e0..b6c402ba33 100644
> --- a/src/sysdep.c
> +++ b/src/sysdep.c
> @@ -4286,8 +4286,33 @@ str_collate (Lisp_Object s1, Lisp_Object s2,
>  }
>  #endif	/* WINDOWSNT */
> =20
> +#ifdef DARWIN_OS
> +
> +/* This function prototype is not in the platform header files. */

Is there any documentation you could refer to, even only an unofficial =
one?

> +int sandbox_init_with_parameters(const char *profile,
> +                                 uint64_t flags,
> +                                 const char *const parameters[],
> +                                 char **errorbuf);
> +
> +DEFUN ("darwin-sandbox-init", Fdarwin_sandbox_init, =
Sdarwin_sandbox_init,
> +       1, 1, 0,
> +       doc: /* Enter a sandbox whose permitted access is curtailed by =
PROFILE.

I think it would be better to define this as command-line flag, at least =
initially.  That way, the sandbox can protect code that happens early =
on, e.g. the startup code.

This needs to somehow document what PROFILE is.

> +Already open descriptors can be used freely. */)

What does this mean?  Emacs doesn't really expose file descriptors to =
users.

> +  (Lisp_Object profile)
> +{
> +  char *err =3D NULL;
> +  if (sandbox_init_with_parameters (SSDATA (profile), 0, NULL, &err) =
!=3D 0)

Missing CHECK_STRING (profile).

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

Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 15:26:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 11:26:11 2021
Received: from localhost ([127.0.0.1]:44166 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXmpn-000342-FG
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 11:26:11 -0400
Received: from mail235c50.megamailservers.eu ([91.136.10.245]:34146
 helo=mail56c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1lXmpl-00033t-9Z
 for 45198 <at> debbugs.gnu.org; Sat, 17 Apr 2021 11:26:10 -0400
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1618673167;
 bh=E2VpJKBV344x9O4rNkAJi+JoCk2eganvHNpC15QtSCE=;
 h=From:Subject:Date:Cc:To:From;
 b=b2KB5S1cdvRA1opZnAQIpClKkORsnppAnkcLSnFw5w9fonDdGLj+N7RVBGmkNxWdS
 2/2cEhL0dF1zCHHsfU4V7qLvCIzwhgnvO/aOoQhhCvs8G/xIo+egw/ECg1X8loD+YO
 tQbha+X2OYLUtumXogYMl02VoNakHsBOK2htSVhw=
Feedback-ID: mattiase@HIDDEN
Received: from stanniol.lan (c-b952e353.032-75-73746f71.bbcust.telenor.se
 [83.227.82.185]) (authenticated bits=0)
 by mail56c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 13HFQ4DW025686; 
 Sat, 17 Apr 2021 15:26:06 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_2C9CC654-4040-4DAC-ADF8-2E07608D9C8C"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-Id: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@HIDDEN>
Date: Sat, 17 Apr 2021 17:26:03 +0200
To: 45198 <at> debbugs.gnu.org
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A742F15.607AFE0F.0039, 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=FblJO626 c=1 sm=1 tr=0 a=von4qPfY+hyqc0zmWf0tYQ==:117
 a=von4qPfY+hyqc0zmWf0tYQ==:17 a=M51BFTxLslgA:10 a=xcPf1q-u3qo2JXHEquoA:9
 a=CjuIK1q_8ugA:10 a=1P0XLz_2t6KZdAnhmMkA:9 a=De_Ol2h6w80A:10
 a=pHzHmUro8NiASowvMSCR:22 a=Ew2E2A-JSTLzCXPT_086:22
X-Origin-Country: SE
X-Spam-Score: 4.7 (++++)
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:  Slightly updated patch for macOS. Obviously not nearly as
 fancy as the seccomp one but for running something in batch mode that reads
 from files and writes to stdout/stderr it should do. It works and can be
 pushed right away but it would be nice to have a place to use it,
 for validation
 and for tuning the interface. Any plans for that? 
 Content analysis details:   (4.7 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.3 FAKE_REPLY_B           No description available.
 0.4 KHOP_HELO_FCRDNS       Relay HELO differs from its IP's reverse DNS
X-Debbugs-Envelope-To: 45198
Cc: Alan Third <alan@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>,
 Philipp Stephani <p.stephani2@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: 3.3 (+++)
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:  Slightly updated patch for macOS. Obviously not nearly as
   fancy as the seccomp one but for running something in batch mode that reads
    from files and writes to stdout/stderr it should do. It works and can be
   pushed right away but it would be nice to have a place to use it, for validation
    and for tuning the interface. Any plans for that? 
 
 Content analysis details:   (3.3 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.3 FAKE_REPLY_B           No description available.


--Apple-Mail=_2C9CC654-4040-4DAC-ADF8-2E07608D9C8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Slightly updated patch for macOS. Obviously not nearly as fancy as the =
seccomp one but for running something in batch mode that reads from =
files and writes to stdout/stderr it should do.

It works and can be pushed right away but it would be nice to have a =
place to use it, for validation and for tuning the interface. Any plans =
for that?


--Apple-Mail=_2C9CC654-4040-4DAC-ADF8-2E07608D9C8C
Content-Disposition: attachment;
	filename=darwin-sandbox.diff
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="darwin-sandbox.diff"
Content-Transfer-Encoding: 7bit

diff --git a/lisp/subr.el b/lisp/subr.el
index c2be26a15f..4994771c33 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -6262,4 +6262,20 @@ internal--format-docstring-line
 This is intended for internal use only."
   (internal--fill-string-single-line (apply #'format string objects)))
 
+(when (eq system-type 'darwin)
+  (defun sandbox-enter (dirs)
+    "Enter a sandbox only permitting reading files under DIRS.
+DIRS is a list of directory names.  Most other operations such as
+writing files and network access are disallowed.
+Existing open descriptors can still be used freely."
+    (darwin-sandbox-init
+     (concat "(version 1)\n"
+             "(deny default)\n"
+             ;; Emacs seems to need /dev/null; allowing it does no harm.
+             "(allow file-read* (path \"/dev/null\"))\n"
+             (mapconcat (lambda (dir)
+                          (format "(allow file-read* (subpath %S))\n" dir))
+                        dirs ""))))
+  )
+
 ;;; subr.el ends here
diff --git a/src/sysdep.c b/src/sysdep.c
index d940acc4e0..b6c402ba33 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -4286,8 +4286,33 @@ str_collate (Lisp_Object s1, Lisp_Object s2,
 }
 #endif	/* WINDOWSNT */
 
+#ifdef DARWIN_OS
+
+/* This function prototype is not in the platform header files. */
+int sandbox_init_with_parameters(const char *profile,
+                                 uint64_t flags,
+                                 const char *const parameters[],
+                                 char **errorbuf);
+
+DEFUN ("darwin-sandbox-init", Fdarwin_sandbox_init, Sdarwin_sandbox_init,
+       1, 1, 0,
+       doc: /* Enter a sandbox whose permitted access is curtailed by PROFILE.
+Already open descriptors can be used freely. */)
+  (Lisp_Object profile)
+{
+  char *err = NULL;
+  if (sandbox_init_with_parameters (SSDATA (profile), 0, NULL, &err) != 0)
+    error ("sandbox error: %s", err);
+  return Qnil;
+}
+
+#endif	/* DARWIN_OS */
+
 void
 syms_of_sysdep (void)
 {
   defsubr (&Sget_internal_run_time);
+#ifdef DARWIN_OS
+  defsubr (&Sdarwin_sandbox_init);
+#endif
 }
diff --git a/test/src/emacs-tests.el b/test/src/emacs-tests.el
index 09f9a248ef..a1dc7f3501 100644
--- a/test/src/emacs-tests.el
+++ b/test/src/emacs-tests.el
@@ -210,4 +210,74 @@ emacs-tests/bwrap/allows-stdout
           (should (eql status 0)))
         (should (equal (string-trim (buffer-string)) "Hi"))))))
 
+(defun emacs-tests--darwin-run-sandboxed-emacs (sandbox-dirs body)
+  "Run Emacs and evaluate BODY, only allowing reads from SANDBOX-DIRS.
+If SANDBOX-DIRS is `no-sandbox', then run without sandbox.
+Return (EXIT-STATUS . OUTPUT), where OUTPUT is stderr and stdout."
+  (let ((emacs (expand-file-name invocation-name invocation-directory))
+        (process-environment nil))
+    (with-temp-buffer
+      (let* ((prog `(progn
+                      ,@(and (not (eq sandbox-dirs 'no-sandbox))
+                             `((sandbox-enter ',sandbox-dirs)))
+                      ,@body))
+             (res (call-process emacs nil t nil
+                                "--quick" "--batch"
+                                (format "--eval=%S" prog))))
+        (cons res (buffer-string))))))
+
+(ert-deftest emacs-tests/darwin-sandbox ()
+  (skip-unless (eq system-type 'darwin))
+  (emacs-tests--with-temp-file test-file ("test")
+    (let ((some-text "abcdef")
+          (other-text "ghijkl")
+          (test-file (file-truename test-file)))   ; resolve symlinks
+      (with-temp-buffer
+        (insert some-text)
+        (write-file test-file))
+
+      ;; Read the file without allowing its directory -- should fail.
+      (let ((res-out (emacs-tests--darwin-run-sandboxed-emacs
+                      nil
+                      `((find-file-literally ,test-file)
+                        (message "OK: %s" (buffer-string))))))
+        (ert-info ((cdr res-out) :prefix "output: ")
+          (should-not (equal (car res-out) 0))
+          (should-not (string-search some-text (cdr res-out)))))
+
+      ;; Read the file allowing its directory -- should succeed.
+      (let ((res-out (emacs-tests--darwin-run-sandboxed-emacs
+                      (list (file-name-directory test-file))
+                      `((find-file-literally ,test-file)
+                        (message "OK: %s" (buffer-string))))))
+        (should (equal res-out (cons 0 (format "OK: %s\n" some-text)))))
+
+      ;; Write to the file allowing directory reads -- should fail.
+      (let ((res-out (emacs-tests--darwin-run-sandboxed-emacs
+                      (list (file-name-directory test-file))
+                      `((with-temp-buffer
+                          (insert ,other-text)
+                          (write-file ,test-file))))))
+        (ert-info ((cdr res-out) :prefix "output: ")
+          (should-not (equal (car res-out) 0))
+          ;; The file should be unchanged.
+          (let ((contents (with-temp-buffer
+                            (insert-file-literally test-file)
+                            (buffer-string))))
+            (should (equal contents some-text)))))
+
+      ;; Write to the file without sandbox -- should succeed.
+      (let ((res-out (emacs-tests--darwin-run-sandboxed-emacs
+                      'no-sandbox
+                      `((with-temp-buffer
+                          (insert ,other-text)
+                          (write-file ,test-file))))))
+        (ert-info ((cdr res-out) :prefix "output: ")
+          (should (equal (car res-out) 0))
+          ;; The file should be changed.
+          (let ((contents (with-temp-buffer
+                            (insert-file-literally test-file)
+                            (buffer-string))))
+            (should (equal contents other-text))))))))
+
 ;;; emacs-tests.el ends here

--Apple-Mail=_2C9CC654-4040-4DAC-ADF8-2E07608D9C8C--

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

Received: (at 45198) by debbugs.gnu.org; 10 Apr 2021 19:11:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 10 15:11:24 2021
Received: from localhost ([127.0.0.1]:53305 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lVJ0t-0004VC-S0
	for submit <at> debbugs.gnu.org; Sat, 10 Apr 2021 15:11:24 -0400
Received: from mail-ot1-f54.google.com ([209.85.210.54]:34458)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lVJ0s-0004V0-04
 for 45198 <at> debbugs.gnu.org; Sat, 10 Apr 2021 15:11:22 -0400
Received: by mail-ot1-f54.google.com with SMTP id
 k14-20020a9d7dce0000b02901b866632f29so8973538otn.1
 for <45198 <at> debbugs.gnu.org>; Sat, 10 Apr 2021 12:11:22 -0700 (PDT)
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=ruJ4QHLp7a4fFzpbcBhKo12EM0invYehhtFqJ962ZNU=;
 b=Diro42WXgwvZyguRopRAkza1JcP/vJ3PvPYGoOgvIgE7+KuTeGKxz9EcQ1fPeUGNwK
 Rb5F11FsvKeLO593ZeOoK96w2C2NXN9V+qVKl10uoK3lQSl+mCSF5jW6Dda6znu3fWnb
 51jyo9mHV76JZJun8o4yBN2FL78VPckZHnU0zE33/9PJ2Hqg6vqqpX+6wwDCGW3vnLLZ
 PD9ml9yE0fKKpAeEVVKtlU+Rwt2unkPnYjek0op4k2aupnEsg/yLJcgHlWNmPYLEu0lQ
 IIENSsa9VK5zJpiEoZlMFiZO9Bpo9T4fTjRbhmP6GlYG1WEt1PckujKnoNoQ++NTWraG
 F0Lw==
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=ruJ4QHLp7a4fFzpbcBhKo12EM0invYehhtFqJ962ZNU=;
 b=c5feQtevCtwhv0l3Oet4nzDCjhvnN30XnzcqX1pOYYmoft5yoQ87XEq/rWrZ7F2gD/
 Fo83d7cmaX3WetFGVLwuSuzXFoV03FuIbCKtfY4mmYnxqiUL+IAgD6GTg7PwX7oxvDTv
 o8Q2vHGwZ9+TLpoYN+aJyOdpembS64Ax4jBMWtNJoMa0VANwVsJHncV2zQNLNZBygqOl
 rARFveKCUSBYhFI8/sHACWFmdf9QC1vgCuWq7vhnQ/ufLRHMRrl6KE8/ceBcKQfyLvlu
 txorQYYN+WOGbF4X2vmhLPhh3u/YlWJaa3V4VX93bLCJVwZm1d6Q34UHMzlBuee0j/YV
 ChdQ==
X-Gm-Message-State: AOAM530/si1DkVjtPtM6JWNCyJjw//Ht6JDlWdFQtlKbtGQVIkcgkSM5
 msD6n7DTV3GLs0zV5I9YRhGA8N15XXH3u29XiD4=
X-Google-Smtp-Source: ABdhPJxHt1PS64c9BsBeZHyB0TaQfsMWpV9KwC1XqSU9yrgPHYKaOELWuZIYuT8txkwAER6Bk1GKo43UuTWqW1opx4g=
X-Received: by 2002:a05:6830:4121:: with SMTP id
 w33mr16993553ott.153.1618081876336; 
 Sat, 10 Apr 2021 12:11:16 -0700 (PDT)
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>
In-Reply-To: <CAArVCkREr5S=k42mXhW8dMzAtmiv7AG8m5yTSFZ72Bey14=9tw@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 10 Apr 2021 21:11:04 +0200
Message-ID: <CAArVCkRerqZtmDsBAYNA-92tY7qGOmBwMy85YqTj=iAuoVNv2g@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@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,
 =?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 Sa., 19. Dez. 2020 um 23:22 Uhr schrieb Philipp Stephani
<p.stephani2@HIDDEN>:
>
> 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 nee=
ds
> > > > to install a mount namespace that only allows read access to Emacs'=
s
> > > > installation directory plus any input file and write access to know=
n
> > > > output files, and enable syscall filters that forbid everything exc=
ept
> > > > 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.

I've now pushed a variant of this patch as commit
1060289f51ee1bf269bb45940892eb272d35af97, after verifying that it
doesn't break the macOS or Windows builds.

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

Received: (at 45198) by debbugs.gnu.org; 10 Apr 2021 17:45:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 10 13:45:04 2021
Received: from localhost ([127.0.0.1]:53204 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lVHfL-0006Yi-Vk
	for submit <at> debbugs.gnu.org; Sat, 10 Apr 2021 13:45:04 -0400
Received: from mail-oi1-f171.google.com ([209.85.167.171]:43734)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1lVHfK-0006Xy-Rv
 for 45198 <at> debbugs.gnu.org; Sat, 10 Apr 2021 13:45:03 -0400
Received: by mail-oi1-f171.google.com with SMTP id n8so9193401oie.10
 for <45198 <at> debbugs.gnu.org>; Sat, 10 Apr 2021 10:45:02 -0700 (PDT)
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=gwxecy6Vc1oV3tC5nx3nBkQyxqUlHkbFxif2f4PlapE=;
 b=i0S0rH08oyPX76sH5jm2o9IeZTI+fWUoOzYIm9WnXsN9IywlPu1gaLpHP4YZK9X5B8
 pQwrF6DdyDvSqdw1v1zUnR8reiWgsMuW1mlPjzjBt6CfReS6np3AL/xvlme66sKWYlSL
 Kga3yPWwNvSjaHb3xc1by1VQ6oryDVhxkTgoUje6nJfkU+WHI/1iJ+Gz58aO2di2KmOj
 ZKVJIdpue5O+rqpvnIdgdou8pNdmvcBJOYMyAILCNPBUzp83aIPL/3fPqGC0k9lPaKCB
 fTzicVFopMxpSUBSB25wZ17qA431btpr/+B7A0Td380alKG8YzmQGSbsbS5fghm40Lps
 x4mg==
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=gwxecy6Vc1oV3tC5nx3nBkQyxqUlHkbFxif2f4PlapE=;
 b=S+elxG/qh/6rlBsG+zO+Q3ezbm5fhy2KxFofcb22AHBTwiOtU126JBv30bdI25eda5
 nWCNJxYAthwEENPVvZ2pAIV6bc6dY7hpaJWOGTcyEzB/uG8I0VRWs2EwDMfzWqejBntH
 wZpXwyOKW+oZWpa/kG3G7QOwhulxDM33pokDzXb8irPoUSR0Wt0vsJSkkWEsOD+kJP9h
 JQHuTdhtxFka1JrkCRNcDVUcQu4n8Tz0pn+dj0CB0p8tuzS6zwkuvLPxNSNOQ/2Inflk
 IatTZZqmYE9e4mIiNCOBgC2jqcf7TmuSBh6zDKgvjPIJhc9TyVW/WHqgY7mV6BODC15U
 uf5A==
X-Gm-Message-State: AOAM533p3hb+9ABOo4PfOYcQ2L9FKS+7SP9xMVy0+tn0DLIy44ZsKYYi
 AFYXirVOGB0WyIK0K2IbtbLYN1vwAVcDp7zgjZQ=
X-Google-Smtp-Source: ABdhPJzPH7i3d6HBYblyZaAh86E8cs2GaqjXpUlGzpJMPy8HQZaTUx6/KVh3DuZVvmZ0JgCBF1rPBDqsQVq0ECP4JlQ=
X-Received: by 2002:aca:6543:: with SMTP id j3mr14327382oiw.158.1618076697017; 
 Sat, 10 Apr 2021 10:44:57 -0700 (PDT)
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>
 <CAArVCkSiTR6UBT3AcKYOe3Yr8TgizjVBOobF_PDv0JNUySj2CA@HIDDEN>
In-Reply-To: <CAArVCkSiTR6UBT3AcKYOe3Yr8TgizjVBOobF_PDv0JNUySj2CA@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sat, 10 Apr 2021 19:44:45 +0200
Message-ID: <CAArVCkRDhDNUhivOeJLSP0pH8JF8S830-1Hm2C3G8Dwcjjz0-g@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., 19. Dez. 2020 um 19:18 Uhr schrieb Philipp Stephani
<p.stephani2@HIDDEN>:
>
> 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.

I've verified that a slight variant of this patch doesn't break either
the Windows or macOS builds, and pushed it to master as commit
be8328acf9aa464f848e682e63e417a18529af9e.

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

Received: (at 45198) by debbugs.gnu.org; 31 Dec 2020 16:50:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 31 11:50:39 2020
Received: from localhost ([127.0.0.1]:41472 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kv19r-0002Rp-Ji
	for submit <at> debbugs.gnu.org; Thu, 31 Dec 2020 11:50:39 -0500
Received: from eggs.gnu.org ([209.51.188.92]:46882)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kv19q-0002Rc-Qg
 for 45198 <at> debbugs.gnu.org; Thu, 31 Dec 2020 11:50:39 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:52260)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kv19j-0005E6-JV; Thu, 31 Dec 2020 11:50:33 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3077
 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 1kv19i-00023j-9p; Thu, 31 Dec 2020 11:50:31 -0500
Date: Thu, 31 Dec 2020 18:50:07 +0200
Message-Id: <83im8hhqdc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <CAArVCkT=PmqsBjREFfcrVHRAXjtjfVvTH4uvL9_pARvor4pgQQ@HIDDEN>
 (message from Philipp Stephani on Thu, 31 Dec 2020 16:05:52 +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>
 <CAArVCkR=BwguqGBQFO5pjYJZOmHTX-RJGKmUL9Bon-F1fUNSWQ@HIDDEN>
 <838s9gk476.fsf@HIDDEN>
 <CAArVCkQAHJCv7ZQfytsrZqBg4Dn0tBsCcjWcpkjkpCzH3CCMrw@HIDDEN>
 <834kk4k090.fsf@HIDDEN>
 <CAArVCkT=PmqsBjREFfcrVHRAXjtjfVvTH4uvL9_pARvor4pgQQ@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: Thu, 31 Dec 2020 16:05:52 +0100
> Cc: Stefan Monnier <monnier@HIDDEN>, Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org, 
> 	João Távora <joaotavora@HIDDEN>
> 
> Am Di., 29. Dez. 2020 um 18:09 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
> >
> > Because some/many Gnulib replacements are incompatible with how the
> > w32 port of Emacs works.  In particular, functions which operate on
> > file names don't support UTF-8 encoded file names; Gnulib's 'stat' and
> > 'fstat' don't support security-related features from which we glean
> > owner and group of files; network-related functions need special
> > handling in Emacs to support subprocess functionality; etc.
> 
> That's a fair point, but does the mere presence of these replacements
> really break the build?

If the function compiles cleanly and is not used on MS-Windows, then
no, the build won't break.

> Could we somehow make them not break the build?

It's not up to us, because we don't maintain Gnulib code.  And it
isn't always practical, since the Windows port of Emacs has its own
replacements for some Posix functionality that conflict with the
Gnulib replacements.

> > I know; I wrote that.  However, this talks about code that will be
> > actually _used_ in the Windows build, whereas here we are talking
> > about "ballast": the related code will not be used at all.  So it
> > makes sense not to make our job harder by adding unnecessary code,
> > which then will need to be audited for compatibility.  Your Gnulib
> > import adds quite a lot of modules, which makes the audit a large job.
> 
> Independent of this discussion, are there ways to reduce the size of
> the auditing job? I'd hope that eventually the only thing needed would
> be to run the test suite (which ideally would happen automatically on
> Gitlab/Emba).

The test suite is doesn't yet have enough coverage.  And if Emacs
fails to build, the test suite cannot help.

> For developers not on Windows, it's unfortunately difficult to predict
> whether a specific change will break the Windows build or not, and the
> large difference between the Windows and other builds doesn't make
> this easier.

Sure, that's when posting a patch or a separate branch are a good
means to let the code be fixed before it lands.

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

Received: (at 45198) by debbugs.gnu.org; 31 Dec 2020 15:06:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 31 10:06:11 2020
Received: from localhost ([127.0.0.1]:41262 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kuzWl-0008F7-2t
	for submit <at> debbugs.gnu.org; Thu, 31 Dec 2020 10:06:11 -0500
Received: from mail-oi1-f170.google.com ([209.85.167.170]:34237)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kuzWj-0008Eq-CM
 for 45198 <at> debbugs.gnu.org; Thu, 31 Dec 2020 10:06:10 -0500
Received: by mail-oi1-f170.google.com with SMTP id s75so22080275oih.1
 for <45198 <at> debbugs.gnu.org>; Thu, 31 Dec 2020 07:06: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:content-transfer-encoding;
 bh=gCpSkdnajqlsmVxlxtmIij79CuTU52UYUJAAy24CDyY=;
 b=JAk/J8f1hjlgzdbUBm4ys6ys61FG/loOZKmMSXD+NtmN/SOg/s5TEcE594x/I9vK+u
 Qsv8UtkRHmqhQTCuF/SHoRe3fnebpNIDCfZpix+msqHIUzg1baM3GmUeuAOy93/GegUo
 N2s3g8+K3rnbWUE1RNFmHB4vY8ax+aSxSkInv+UBJGAauVPFjoxWs0Tfjmx6aEiTCbR1
 h8qrDLMWc6CRsX1Nz4xkL9GEWhALMBhWpWXrR1OalY2hf46Mdji2v7JyjMxloHftlMZm
 zbNHdTXu7DKydOK+fRgcW/iSlSCK17zFjHGd2Jjv9PDYJ0UDbpNEGM3y4SPwPHMB4CrR
 NFsw==
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=gCpSkdnajqlsmVxlxtmIij79CuTU52UYUJAAy24CDyY=;
 b=H6TLCd/e3SXxALkR/GhpdGXvAOKePake+Moww6jz5+Icql372ZcI9Sjy+g86rU08bR
 /RxDd1tdMNY1Wl0ui4mSAc51pMsF8Rt03j6DKSzOlb60SMIon9lJirsh/3t8tuGUTsEW
 ZTp60DEaMO8RpIBB1LVVJ6Kkq+MeQWLoXTNX+jx75sQKJBRZuPGWqmc8+vanxxMEcHrU
 0hddlmnkRSqdSkxUze6FVY0DhcOFP7YlgVMd34eh4UbvYuEqMb9hJe+6ejz46WFvOAAb
 mW9jVrOGDoILpTVVIV9eRNMOi0LS9ab59sx8+/74o0yaKb/wxOlTcAtbrXL6fOZcV2l1
 7+Fw==
X-Gm-Message-State: AOAM532guj+KW1mPaiqbGkUq8m5JCmNABMHNDenwKy/M+SJzca9w8fQl
 oUMZHYHkCwwb97sOUF7GpbfHK1BhcnPIDLS5lms=
X-Google-Smtp-Source: ABdhPJxymbfGPyU+RGA7E4gCo357blvhSydfXMv9pz6egY3ELfQWaCrZ8RX/evlcTwQU9DAJmpJqVIyaDLMck4HAaRQ=
X-Received: by 2002:a54:4881:: with SMTP id r1mr8036307oic.9.1609427163664;
 Thu, 31 Dec 2020 07:06: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>
 <CAArVCkREr5S=k42mXhW8dMzAtmiv7AG8m5yTSFZ72Bey14=9tw@HIDDEN>
 <CAArVCkR=BwguqGBQFO5pjYJZOmHTX-RJGKmUL9Bon-F1fUNSWQ@HIDDEN>
 <838s9gk476.fsf@HIDDEN>
 <CAArVCkQAHJCv7ZQfytsrZqBg4Dn0tBsCcjWcpkjkpCzH3CCMrw@HIDDEN>
 <834kk4k090.fsf@HIDDEN>
In-Reply-To: <834kk4k090.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Thu, 31 Dec 2020 16:05:52 +0100
Message-ID: <CAArVCkT=PmqsBjREFfcrVHRAXjtjfVvTH4uvL9_pARvor4pgQQ@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.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 Di., 29. Dez. 2020 um 18:09 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
>
> > From: Philipp Stephani <p.stephani2@HIDDEN>
> > Date: Tue, 29 Dec 2020 17:05:33 +0100
> > Cc: Stefan Monnier <monnier@HIDDEN>, Bastien <bzg@HIDDEN>, 4=
5198 <at> debbugs.gnu.org,
> >       Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
> >
> > Am Di., 29. Dez. 2020 um 16:44 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>=
:
> > >
> > > > It would be great if someone could test whether the Windows build
> > > > still works after that, thanks!
> > >
> > > I only skimmed the changes, but I'm already quite sure they will brea=
k
> > > the Windows build.
> >
> > Why? Everything should be behind ifdefs/conditional compilation,
> > otherwise compilation on macOS would also break.
>
> Because some/many Gnulib replacements are incompatible with how the
> w32 port of Emacs works.  In particular, functions which operate on
> file names don't support UTF-8 encoded file names; Gnulib's 'stat' and
> 'fstat' don't support security-related features from which we glean
> owner and group of files; network-related functions need special
> handling in Emacs to support subprocess functionality; etc.

That's a fair point, but does the mere presence of these replacements
really break the build? Could we somehow make them not break the
build?

>
> > >   . Gnulib modules pulled to support seccomp should be disabled in th=
e
> > >     MS-Windows build, by suitable changes to nt/mingw-cfg.site and/or
> > >     nt/gnulib-cfg.mk; and
> >
> > This shouldn't be necessary, as Gnulib is compatible with Windows (I
> > guess, since we use it elsewhere)
>
> Not when Emacs is concerned, see above.  We use only small parts of
> Gnulib on Windows, for those reasons.  And we don't use any Gnulib
> functions that accept file names.
>
> > (That's also what gnulib-cfg.mk says: "In general, do NOT omit modules
> > that don't need to be omitted, to minimize the differences from
> > upstream gnulib.mk and thus make the maintenance easier.")
>
> I know; I wrote that.  However, this talks about code that will be
> actually _used_ in the Windows build, whereas here we are talking
> about "ballast": the related code will not be used at all.  So it
> makes sense not to make our job harder by adding unnecessary code,
> which then will need to be audited for compatibility.  Your Gnulib
> import adds quite a lot of modules, which makes the audit a large job.

Independent of this discussion, are there ways to reduce the size of
the auditing job? I'd hope that eventually the only thing needed would
be to run the test suite (which ideally would happen automatically on
Gitlab/Emba).
For developers not on Windows, it's unfortunately difficult to predict
whether a specific change will break the Windows build or not, and the
large difference between the Windows and other builds doesn't make
this easier.

>
> > >   . header files used to support seccomp code should be #ifdef'ed by
> > >     HAVE_LINUX_SECCOMP_H or similar, and likewise with any code neede=
d
> > >     for seccomp and unnecessary otherwise.
> >
> > That should already be the case.
>
> It isn't, at least not in general.  Just one example:
>
>   diff --git a/src/emacs.c b/src/emacs.c
>   index 2a32083..a044535 100644
>   --- a/src/emacs.c
>   +++ b/src/emacs.c
>   @@ -33,6 +33,8 @@ along with GNU Emacs.  If not, see <https://www.gnu.o=
rg/licenses/>.  */
>    #include "lisp.h"
>    #include "sysstdio.h"
>
>   +#include <read-file.h>  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> This header is included unconditionally, although it shouldn't be
> needed on Windows.

Sure, it's not needed, but does it actually break the build? I'd
rather limit the number of preprocessor statements as much as possible
(and reasonable).

>
> > Turning the question around: is building the branch on Windows
> > actually broken? If so, what are the error messages?
>
> I didn't have time to build it, and probably won't have enough time in
> the following days, sorry.  I have the co-maintainer job to do, and
> there's a pretest of Emacs 27.2 under way on top of that.  So I cannot
> show the error messages.  Others are encouraged to try the branch and
> report the actual problems; I just wanted to give a heads-up, in the
> hope that it will help adapting and merging the branch sooner.

Thanks, no pressure, this clearly isn't urgent.

>
> > > Btw, I wonder why you needed to import the read-file module from
> > > Gnulib -- does it provide any features that we couldn't implement on
> > > our own?  I'm asking because that module caused you to pull in quite =
a
> > > few dependency modules from Gnulib, and I'm asking myself whether tha=
t
> > > is really justified.
> >
> > We could implement it ourselves, if we wanted, and in an earlier
> > version of the code I did that. But it's easier and less error-prone
> > to reuse an existing library.
>
> I question the wisdom of that, FWIW.  Every unnecessary dependency on
> Gnulib is IMO an addition to the maintenance burden.  It also makes
> the job of adapting the Windows build harder, because for example
> Gnulib's fopen cannot be used in Emacs on Windows, whereas we have
> emacs_fopen for the same purpose, which doesn't have that problem.

Yeah, there are pros and cons for either approach. Typically, reusing
code is the way to go, since code is a liability, and the less we have
to maintain, the better. But I do see your point that using Gnulib is
too much of a burden for Windows right now (though I still hope that
we can eventually improve Gnulib enough that we can use it directly on
Windows). I've now created a new branch scratch/seccomp-no-gnulib-2
that uses fopen directly, without Gnulib dependencies. (I considered
using emacs_fopen, but since that allows users to quit and therefore
in theory can run Lisp code, I'm not sure we can use it here. Also,
since this only works on GNU/Linux, we don't have to deal with Windows
filenames.)

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

Received: (at 45198) by debbugs.gnu.org; 30 Dec 2020 15:36:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 30 10:36:46 2020
Received: from localhost ([127.0.0.1]:50717 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kudWo-0006en-Fj
	for submit <at> debbugs.gnu.org; Wed, 30 Dec 2020 10:36:46 -0500
Received: from outbound.soverin.net ([116.202.65.218]:36505)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <alan@HIDDEN>) id 1kudWm-0006eV-Lr
 for 45198 <at> debbugs.gnu.org; Wed, 30 Dec 2020 10:36:45 -0500
Received: from smtp.soverin.net (unknown [10.10.3.28])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
 (No client certificate requested)
 by outbound.soverin.net (Postfix) with ESMTPS id 5CF476008F;
 Wed, 30 Dec 2020 15:36:38 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by
 soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin;
 t=1609342597; bh=iZILMyrvBuuYXvd+s9VRav7wlKwDGTrXRS94DP+a4tY=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=HQGSelwE2etuha3fZtpCJoE5VubFpF882y3nCoxvw4bRW4UAbRNmrqP7FK5cCMsyD
 V8A0RkzZjcUxzOQOcntZwjKQFJ/mgORW8vDhsksmOeXAu7Ng9t0ySnuzgL6D99UvNE
 VDYZnB5gyiNPTUdSRvtYsPp4KIjCe0Bj8UcIH7ni7sLmicSSDfp6x6FnyO/LKe8bp/
 XeG479IzP1jPfjNHQijbfY1hPsSVGZ0ccR+Lmamake2gFJJ+2OQkM8B5Olt4BPFMN4
 pLeThZQYgqG9GydAfrUwky1/Xl/oBgCVkmJ2t80GGhZSKr/iejVjWMdI60PQIWO1qf
 az4MlOC96BbOg==
Received: by breton.holly.idiocy.org (Postfix, from userid 501)
 id 8EAF920295BE6B; Wed, 30 Dec 2020 15:36:33 +0000 (GMT)
Date: Wed, 30 Dec 2020 15:36:33 +0000
From: Alan Third <alan@HIDDEN>
To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= <mattiase@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <X+yegeZKr5VjAp1p@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
 Mattias =?iso-8859-1?Q?Engdeg=E5rd?= <mattiase@HIDDEN>,
 45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN>,
 Bastien <bzg@HIDDEN>, Stefan Monnier <monnier@HIDDEN>,
 =?iso-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN>,
 Philipp Stephani <p.stephani2@HIDDEN>
References: <F6832EA6-7059-4F6A-A028-771D063DD8CB@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F6832EA6-7059-4F6A-A028-771D063DD8CB@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45198
Cc: 45198 <at> debbugs.gnu.org, Bastien <bzg@HIDDEN>,
 Philipp Stephani <p.stephani2@HIDDEN>,
 =?iso-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>,
 Stefan Kangas <stefankangas@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.7 (-)

On Wed, Dec 30, 2020 at 03:59:19PM +0100, Mattias Engdegård wrote:
> Here is a bare-bones macOS sandbox implementation. In practice, it
> would probably be called in an --eval argument to guard anything
> executed later. It should be sufficient for the typical untrusted
> flymake checker running in an Emacs subprocess and printing to
> stdout/stderr.

It may make more sense to use darwin instead of macos in the name,
unless it is actually specific to macOS.

I believe OpenDarwin is still a thing.

-- 
Alan Third

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

Received: (at 45198) by debbugs.gnu.org; 30 Dec 2020 14:59:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 30 09:59:28 2020
Received: from localhost ([127.0.0.1]:50533 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kucwi-0005WN-1O
	for submit <at> debbugs.gnu.org; Wed, 30 Dec 2020 09:59:28 -0500
Received: from mail205c50.megamailservers.eu ([91.136.10.215]:56796
 helo=mail193c50.megamailservers.eu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mattiase@HIDDEN>) id 1kucwf-0005W4-4e
 for 45198 <at> debbugs.gnu.org; Wed, 30 Dec 2020 09:59:26 -0500
X-Authenticated-User: mattiase@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu;
 s=maildub; t=1609340363;
 bh=F6FuE04fNiqMycyD6dDQBbOboz6a//MCtgyXf6qqiQ8=;
 h=From:Subject:Date:Cc:To:From;
 b=LIYping6Q4XAfDD1lcN8mHGbL/+bec59+V0CjXJ+Iyr56viwcLiz3EtwLuhVuOiGN
 XPUF8BcXgyehUS5UZB85JgMCkUJPEApiRQF5ASP/koI2Dvz+wzyrYY6JeLKiDPWvoa
 xThXKR3ucKvayal4c3C4syLnmH0O7pwVyO2bSF28=
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 mail193c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0BUExKEk021256; 
 Wed, 30 Dec 2020 14:59:21 +0000
From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_D73D3F94-4567-4C01-8C2E-AC319FE69E44"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-Id: <F6832EA6-7059-4F6A-A028-771D063DD8CB@HIDDEN>
Date: Wed, 30 Dec 2020 15:59:19 +0100
To: 45198 <at> debbugs.gnu.org
X-Mailer: Apple Mail (2.3445.104.17)
X-CTCH-RefID: str=0001.0A742F1A.5FEC95CB.0027, 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=SF+I6pRkHZhrawxbOkkvaA==:117
 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=M51BFTxLslgA:10 a=OCr-RfVi6S2wSVDVX0wA:9
 a=CjuIK1q_8ugA:10 a=yiRCvGavlT-ZiGpzhI4A:9 a=De_Ol2h6w80A:10
 a=pHzHmUro8NiASowvMSCR:22 a=Ew2E2A-JSTLzCXPT_086:22
X-Origin-Country: SE
X-Spam-Score: 3.2 (+++)
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: Here is a bare-bones macOS sandbox implementation. In
 practice, 
 it would probably be called in an --eval argument to guard anything executed
 later. It should be sufficient for the typical untrusted fl [...] 
 Content analysis details:   (3.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [91.136.10.215 listed in list.dnswl.org]
 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)
 2.2 FAKE_REPLY_B           No description available.
X-Debbugs-Envelope-To: 45198
Cc: Alan Third <alan@HIDDEN>, Bastien <bzg@HIDDEN>,
 Philipp Stephani <p.stephani2@HIDDEN>,
 =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>,
 Stefan Kangas <stefankangas@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: 2.2 (++)
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:  Here is a bare-bones macOS sandbox implementation. In practice,
    it would probably be called in an --eval argument to guard anything executed
    later. It should be sufficient for the typical untrusted fl [...] 
 
 Content analysis details:   (2.2 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [91.136.10.215 listed in list.dnswl.org]
  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
  2.2 FAKE_REPLY_B           No description available.


--Apple-Mail=_D73D3F94-4567-4C01-8C2E-AC319FE69E44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Here is a bare-bones macOS sandbox implementation. In practice, it would =
probably be called in an --eval argument to guard anything executed =
later. It should be sufficient for the typical untrusted flymake checker =
running in an Emacs subprocess and printing to stdout/stderr.


--Apple-Mail=_D73D3F94-4567-4C01-8C2E-AC319FE69E44
Content-Disposition: attachment;
	filename=macos-sandbox.diff
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="macos-sandbox.diff"
Content-Transfer-Encoding: 7bit

diff --git a/lisp/subr.el b/lisp/subr.el
index ed0d6978d0..729c4ac70b 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -6036,4 +6036,18 @@ internal--format-docstring-line
 This is intended for internal use only."
   (internal--fill-string-single-line (apply #'format string objects)))
 
+(defun sandbox-enter (dirs)
+  "Enter a sandbox only permitting reading files under DIRS.
+DIRS is a list of directory names.  Most other operations such as
+writing files and network access are disallowed.
+Existing open descriptors can still be used freely."
+  (unless (eq system-type 'darwin)
+    (error "not implemented on this platform"))
+  (macos-sandbox-init
+   (concat "(version 1)\n"
+           "(deny default)\n"
+           (mapconcat (lambda (dir)
+                        (format "(allow file-read* (subpath %S))\n" dir))
+                      dirs ""))))
+
 ;;; subr.el ends here
diff --git a/src/sysdep.c b/src/sysdep.c
index eeb9d18494..3b2da8c637 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -4054,8 +4054,33 @@ str_collate (Lisp_Object s1, Lisp_Object s2,
 }
 #endif	/* WINDOWSNT */
 
+#ifdef DARWIN_OS
+
+/* This call is not in the platform header files.  You just Have to Know. */
+int sandbox_init_with_parameters(const char *profile,
+                                 uint64_t flags,
+                                 const char *const parameters[],
+                                 char **errorbuf);
+
+DEFUN ("macos-sandbox-init", Fmacos_sandbox_init, Smacos_sandbox_init,
+       1, 1, 0,
+       doc: /* Enter a sandbox whose permitted access is curtailed by PROFILE.
+Already open descriptors can be used freely. */)
+  (Lisp_Object profile)
+{
+  char *err = NULL;
+  if (sandbox_init_with_parameters (SSDATA (profile), 0, NULL, &err) != 0)
+    error ("sandbox error: %s", err);
+  return Qnil;
+}
+
+#endif	/* DARWIN_OS */
+
 void
 syms_of_sysdep (void)
 {
   defsubr (&Sget_internal_run_time);
+#ifdef DARWIN_OS
+  defsubr (&Smacos_sandbox_init);
+#endif
 }

--Apple-Mail=_D73D3F94-4567-4C01-8C2E-AC319FE69E44--

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

Received: (at 45198) by debbugs.gnu.org; 29 Dec 2020 17:09:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 29 12:09:33 2020
Received: from localhost ([127.0.0.1]:40065 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kuIV2-0002Td-Ru
	for submit <at> debbugs.gnu.org; Tue, 29 Dec 2020 12:09:33 -0500
Received: from eggs.gnu.org ([209.51.188.92]:55100)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kuIUz-0002TG-HQ
 for 45198 <at> debbugs.gnu.org; Tue, 29 Dec 2020 12:09:32 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:34551)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kuIUu-00075t-9Y; Tue, 29 Dec 2020 12:09:24 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3156
 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 1kuIUs-0005dl-PV; Tue, 29 Dec 2020 12:09:23 -0500
Date: Tue, 29 Dec 2020 19:09:15 +0200
Message-Id: <834kk4k090.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <CAArVCkQAHJCv7ZQfytsrZqBg4Dn0tBsCcjWcpkjkpCzH3CCMrw@HIDDEN>
 (message from Philipp Stephani on Tue, 29 Dec 2020 17:05:33 +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>
 <CAArVCkR=BwguqGBQFO5pjYJZOmHTX-RJGKmUL9Bon-F1fUNSWQ@HIDDEN>
 <838s9gk476.fsf@HIDDEN>
 <CAArVCkQAHJCv7ZQfytsrZqBg4Dn0tBsCcjWcpkjkpCzH3CCMrw@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: Tue, 29 Dec 2020 17:05:33 +0100
> Cc: Stefan Monnier <monnier@HIDDEN>, Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org, 
> 	João Távora <joaotavora@HIDDEN>
> 
> Am Di., 29. Dez. 2020 um 16:44 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
> >
> > > It would be great if someone could test whether the Windows build
> > > still works after that, thanks!
> >
> > I only skimmed the changes, but I'm already quite sure they will break
> > the Windows build.
> 
> Why? Everything should be behind ifdefs/conditional compilation,
> otherwise compilation on macOS would also break.

Because some/many Gnulib replacements are incompatible with how the
w32 port of Emacs works.  In particular, functions which operate on
file names don't support UTF-8 encoded file names; Gnulib's 'stat' and
'fstat' don't support security-related features from which we glean
owner and group of files; network-related functions need special
handling in Emacs to support subprocess functionality; etc.

> >   . Gnulib modules pulled to support seccomp should be disabled in the
> >     MS-Windows build, by suitable changes to nt/mingw-cfg.site and/or
> >     nt/gnulib-cfg.mk; and
> 
> This shouldn't be necessary, as Gnulib is compatible with Windows (I
> guess, since we use it elsewhere)

Not when Emacs is concerned, see above.  We use only small parts of
Gnulib on Windows, for those reasons.  And we don't use any Gnulib
functions that accept file names.

> (That's also what gnulib-cfg.mk says: "In general, do NOT omit modules
> that don't need to be omitted, to minimize the differences from
> upstream gnulib.mk and thus make the maintenance easier.")

I know; I wrote that.  However, this talks about code that will be
actually _used_ in the Windows build, whereas here we are talking
about "ballast": the related code will not be used at all.  So it
makes sense not to make our job harder by adding unnecessary code,
which then will need to be audited for compatibility.  Your Gnulib
import adds quite a lot of modules, which makes the audit a large job.

> >   . header files used to support seccomp code should be #ifdef'ed by
> >     HAVE_LINUX_SECCOMP_H or similar, and likewise with any code needed
> >     for seccomp and unnecessary otherwise.
> 
> That should already be the case.

It isn't, at least not in general.  Just one example:

  diff --git a/src/emacs.c b/src/emacs.c
  index 2a32083..a044535 100644
  --- a/src/emacs.c
  +++ b/src/emacs.c
  @@ -33,6 +33,8 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
   #include "lisp.h"
   #include "sysstdio.h"

  +#include <read-file.h>  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

This header is included unconditionally, although it shouldn't be
needed on Windows.

> Turning the question around: is building the branch on Windows
> actually broken? If so, what are the error messages?

I didn't have time to build it, and probably won't have enough time in
the following days, sorry.  I have the co-maintainer job to do, and
there's a pretest of Emacs 27.2 under way on top of that.  So I cannot
show the error messages.  Others are encouraged to try the branch and
report the actual problems; I just wanted to give a heads-up, in the
hope that it will help adapting and merging the branch sooner.

> > Btw, I wonder why you needed to import the read-file module from
> > Gnulib -- does it provide any features that we couldn't implement on
> > our own?  I'm asking because that module caused you to pull in quite a
> > few dependency modules from Gnulib, and I'm asking myself whether that
> > is really justified.
> 
> We could implement it ourselves, if we wanted, and in an earlier
> version of the code I did that. But it's easier and less error-prone
> to reuse an existing library.

I question the wisdom of that, FWIW.  Every unnecessary dependency on
Gnulib is IMO an addition to the maintenance burden.  It also makes
the job of adapting the Windows build harder, because for example
Gnulib's fopen cannot be used in Emacs on Windows, whereas we have
emacs_fopen for the same purpose, which doesn't have that problem.

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

Received: (at 45198) by debbugs.gnu.org; 29 Dec 2020 16:05:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 29 11:05:55 2020
Received: from localhost ([127.0.0.1]:40000 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kuHVT-0008Io-7w
	for submit <at> debbugs.gnu.org; Tue, 29 Dec 2020 11:05:55 -0500
Received: from mail-oi1-f169.google.com ([209.85.167.169]:43702)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kuHVO-0008IP-QP
 for 45198 <at> debbugs.gnu.org; Tue, 29 Dec 2020 11:05:54 -0500
Received: by mail-oi1-f169.google.com with SMTP id q25so15015074oij.10
 for <45198 <at> debbugs.gnu.org>; Tue, 29 Dec 2020 08:05: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=de0DtHzrl+qsxf9cvWumYZsmBa16mqCF1k3VrVZ12PM=;
 b=J+OoGylXasoGrmWNav8g/ZJPyTK4aBDD+zPwYa07QV2MglkXMuEjYl/FxA8zefLjDE
 JkGX4Nmh99yOpSVe3jphoMA8vBo0EPMeqwUrjy/YoCs2mYtJU2ZKNfCG9SjsEKdMueC0
 Ny2of40yahMjLuoG4TdOOTBWIXmsVgDj1nyaN9ghrmyKlf6MJphSXTP8n6vKjWKUrun6
 k11ukMGLXASnzVanTGfXEHwzhIy98KkWePBiuUk3GBCwMwOVgd8FknsJXP3Lhar+FEif
 2iJSk806LOIj43G0olVAKZOXJDaaY0sMOGvVIhTQ18WYEtQxXCcJ1fRXptbhODdfRfdz
 DzJA==
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=de0DtHzrl+qsxf9cvWumYZsmBa16mqCF1k3VrVZ12PM=;
 b=OhneUndCEBYKTDeynHizRvhcbtTJ+Pom9PmKJ3gVBzYEMXikgpeyLUGPzFilBnunME
 A5w8G8TZQedZGJR5uMXW47eRn/2Xlwq93MWiUHocG1SdN9Zp4fhr3JEzN2u6t3hPfitD
 x//ol+sFYwoNNbA7pZVzuT+S/wC2Idr9DYlQIOyofd+r4zju/88n9pvAf3hOXgyfZ4Iv
 0uieo/dYSLjn9AkmDWgD0LeBMpAzj3qnhOK3wD0+2VpvIbNbI7XfXlyCsfHsdL6Omx0h
 f4HtB6ZNHq8qHQj4iMbWvEkM0fthZ0B2dfjq9Zv5M3GzdaXdSIcEFthJm8/C4VmDvni4
 mtxg==
X-Gm-Message-State: AOAM532RWmTGtyJCkFKDqt2chRwX4W2XGEEDp6gwLsggP72zOz2bAnQ5
 azE94kDG0KOeCPUniAQycf16VMNDy8CPv9e/22Y=
X-Google-Smtp-Source: ABdhPJxDEv8cNsTMuHjj4NMY7WDicW8AUHhWFONjPE8R+zxaelp/GN9+Esgps5ZJN0wiW6jmEZC+CfcoA+1KtAIqTyE=
X-Received: by 2002:aca:3b03:: with SMTP id i3mr2735536oia.170.1609257944980; 
 Tue, 29 Dec 2020 08:05:44 -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>
 <CAArVCkR=BwguqGBQFO5pjYJZOmHTX-RJGKmUL9Bon-F1fUNSWQ@HIDDEN>
 <838s9gk476.fsf@HIDDEN>
In-Reply-To: <838s9gk476.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 29 Dec 2020 17:05:33 +0100
Message-ID: <CAArVCkQAHJCv7ZQfytsrZqBg4Dn0tBsCcjWcpkjkpCzH3CCMrw@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Eli Zaretskii <eliz@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,
 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 Di., 29. Dez. 2020 um 16:44 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
>
> > It would be great if someone could test whether the Windows build
> > still works after that, thanks!
>
> I only skimmed the changes, but I'm already quite sure they will break
> the Windows build.

Why? Everything should be behind ifdefs/conditional compilation,
otherwise compilation on macOS would also break.

>
> This feature is not relevant to the MS-Windows build of Emacs, at
> least currently (I don't think Windows implements equivalent features
> in a way that is even remotely similar to GNU/Linux).  So to make sure
> the Windows port doesn't break, we must take every measure to avoid
> compiling any of the related code on MS-Windows.  In particular:
>
>   . Gnulib modules pulled to support seccomp should be disabled in the
>     MS-Windows build, by suitable changes to nt/mingw-cfg.site and/or
>     nt/gnulib-cfg.mk; and

This shouldn't be necessary, as Gnulib is compatible with Windows (I
guess, since we use it elsewhere), and the MS C library provides an
emulation layer for some parts of the POSIX API (e.g. file
descriptors). OTOH, conditional compilation incurs a maintenance cost,
so we should avoid it if possible.
(That's also what gnulib-cfg.mk says: "In general, do NOT omit modules
that don't need to be omitted, to minimize the differences from
upstream gnulib.mk and thus make the maintenance easier.")

>   . header files used to support seccomp code should be #ifdef'ed by
>     HAVE_LINUX_SECCOMP_H or similar, and likewise with any code needed
>     for seccomp and unnecessary otherwise.

That should already be the case.
Turning the question around: is building the branch on Windows
actually broken? If so, what are the error messages?

>
> Btw, I wonder why you needed to import the read-file module from
> Gnulib -- does it provide any features that we couldn't implement on
> our own?  I'm asking because that module caused you to pull in quite a
> few dependency modules from Gnulib, and I'm asking myself whether that
> is really justified.

We could implement it ourselves, if we wanted, and in an earlier
version of the code I did that. But it's easier and less error-prone
to reuse an existing library.

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

Received: (at 45198) by debbugs.gnu.org; 29 Dec 2020 15:44:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 29 10:44:11 2020
Received: from localhost ([127.0.0.1]:39967 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kuHAR-0007ch-5q
	for submit <at> debbugs.gnu.org; Tue, 29 Dec 2020 10:44:11 -0500
Received: from eggs.gnu.org ([209.51.188.92]:39486)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kuHAP-0007cT-Tf
 for 45198 <at> debbugs.gnu.org; Tue, 29 Dec 2020 10:44:10 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:32976)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kuHAK-0006DO-7C; Tue, 29 Dec 2020 10:44:04 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1934
 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 1kuHAJ-0002Hc-39; Tue, 29 Dec 2020 10:44:03 -0500
Date: Tue, 29 Dec 2020 17:43:57 +0200
Message-Id: <838s9gk476.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <CAArVCkR=BwguqGBQFO5pjYJZOmHTX-RJGKmUL9Bon-F1fUNSWQ@HIDDEN>
 (message from Philipp Stephani on Tue, 29 Dec 2020 14:50:56 +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>
 <CAArVCkR=BwguqGBQFO5pjYJZOmHTX-RJGKmUL9Bon-F1fUNSWQ@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: Tue, 29 Dec 2020 14:50:56 +0100
> Cc: Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org,
>  João Távora <joaotavora@HIDDEN>
> 
> I've pushed a modified version of these two patches onto the
> scratch/seccomp branch.

Thank you for working on this.

> It would be great if someone could test whether the Windows build
> still works after that, thanks!

I only skimmed the changes, but I'm already quite sure they will break
the Windows build.

This feature is not relevant to the MS-Windows build of Emacs, at
least currently (I don't think Windows implements equivalent features
in a way that is even remotely similar to GNU/Linux).  So to make sure
the Windows port doesn't break, we must take every measure to avoid
compiling any of the related code on MS-Windows.  In particular:

  . Gnulib modules pulled to support seccomp should be disabled in the
    MS-Windows build, by suitable changes to nt/mingw-cfg.site and/or
    nt/gnulib-cfg.mk; and
  . header files used to support seccomp code should be #ifdef'ed by
    HAVE_LINUX_SECCOMP_H or similar, and likewise with any code needed
    for seccomp and unnecessary otherwise.

Btw, I wonder why you needed to import the read-file module from
Gnulib -- does it provide any features that we couldn't implement on
our own?  I'm asking because that module caused you to pull in quite a
few dependency modules from Gnulib, and I'm asking myself whether that
is really justified.

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

Received: (at 45198) by debbugs.gnu.org; 29 Dec 2020 13:58:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 29 08:58:52 2020
Received: from localhost ([127.0.0.1]:38049 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kuFWW-0004Ue-Kd
	for submit <at> debbugs.gnu.org; Tue, 29 Dec 2020 08:58:52 -0500
Received: from mail-ot1-f49.google.com ([209.85.210.49]:42650)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kuFWU-0004UP-Kb
 for 45198 <at> debbugs.gnu.org; Tue, 29 Dec 2020 08:58:51 -0500
Received: by mail-ot1-f49.google.com with SMTP id 11so11850816oty.9
 for <45198 <at> debbugs.gnu.org>; Tue, 29 Dec 2020 05:58: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=HVyu+kna+HQUalY6IvvGMXQks42Ds25EEK/3hqLdmzs=;
 b=Yjy2/1sd7fseXReXfoNOTuNdrPG2GWM04LKfjFUHM2mxA5BrEdrfSEGr3SlYefmBOA
 PtKsktppSpla3HyR5pGELqIqS/3JylZ7d00bV1FXACDwrfHdazJvNwMP0vlf33/OUnqU
 3I8vms2xAWVf+xNVG8aEhQSlwVL7GaxLL3ojTCBXb/KQLz5BZrOUlcvHYuhWmBgXWgum
 scsNHFPlShcIGq3QGrVdWkiuLknDQYsJDkn9VQYXrdTCEklSBioduUDCidkYIzGODtdd
 TvLqVFMAyCZvrd6vVqxC8WFrYt2+Rvt0JaxBAeN2trdVxkqs2CXJRvp3tenRN6lpSnfi
 iGcg==
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=HVyu+kna+HQUalY6IvvGMXQks42Ds25EEK/3hqLdmzs=;
 b=SZUaWdrw374qLmmSwbyh3VUhqvrt9ctsF3JxqVPleuYCZHRIApqEMRWG+QNS33pESX
 g8JjmV3x0daLe/tqxwt5RSG/x9C4XuIyE9m3KF4yFrtkEp26ePkS5KewXo0w9GndxRJw
 CPsz21jq4Z6rM6hPqS5DiAMirjbZp5lmah3+fEGzfisW3z47oJh0E4uotRmVOjg2c/AL
 X9jeXsU7evxnwLWzg7Rt5AaGNCbFS2RPXEH4WZ9VI5EjaiDoj+5wWIG6TsdVilrjc1iZ
 UB2woRf6P/271baZo5Vog3AwWF+B8p3s9d7qTEDzLAB5E2Yrg21NVNJtRD+LV0iwTgiZ
 KYow==
X-Gm-Message-State: AOAM531htafizMfO8bVXfTbmCOwmvge5B/TiHckQ/xuOoDs6+nka7axj
 r/3Vd4oFd+A5th4t9CgT3MzdoIsfpFHzMK8GtRg=
X-Google-Smtp-Source: ABdhPJx9mkp4EdOIhnolTRU0B+NSwqz8IP7VCBJ26p9ZW7Be5bOakVHSXDGBi6BYyYBvdFweBP5g6mguUuMf1up9FPA=
X-Received: by 2002:a9d:269:: with SMTP id 96mr35840463otb.174.1609250324758; 
 Tue, 29 Dec 2020 05:58:44 -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>
 <CAArVCkST2aCAa3a3YbNZEpysek0HrwPDsVDBRtt4=NSYXFObRQ@HIDDEN>
 <CADwFkm=Jjx3EnF6SYYNr=hFFLWuL=ZFeuMVhyOprbufydN9Dkg@HIDDEN>
In-Reply-To: <CADwFkm=Jjx3EnF6SYYNr=hFFLWuL=ZFeuMVhyOprbufydN9Dkg@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 29 Dec 2020 14:58:33 +0100
Message-ID: <CAArVCkSupEERq11HhSBY_GWA+SyU-b+aRHc8auY=VABPZ7LFgw@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Kangas <stefankangas@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 45198
Cc: Bastien <bzg@HIDDEN>,
 =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@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., 28. Dez. 2020 um 09:23 Uhr schrieb Stefan Kangas
<stefankangas@HIDDEN>:
>
> Philipp Stephani <p.stephani2@HIDDEN> writes:
>
> > I agree, but we should use the time until Emacs 28 gets released to
> > gain experience with the API as well, so we should design the API
> > rather sooner than later, because once Emacs 28 is released, we can't
> > change it any more in incompatible ways.
>
> IMO, we could release it as an experimental feature and prominently
> announce that API changes might happen between major versions of Emacs.
> That would give us room to make even backward-incompatible changes,
> if/when necessary.
>
> I don't necessarily advocate this; I only want to point out that this is
> an option.

It's an option, though I'm not sure whether such announcements really
work all that well. Once an API becomes widely used, it becomes hard
to change it, even if it was announced to be unstable. Thus I'd
advocate for starting with the most conservative and malleable
approach possible:
- Don't allow reading the entire filesystem, but only selected files
and directories.
- Don't allow writing files (for now), communication should happen
through stdout. (That's probably good enough for Flymake, but soon
we'll need to find a more flexible approach.)
- Don't return a process object, but an opaque sandbox object.

For example:

(cl-defun start-sandbox (function &key readable-directories stdout-buffer) ...)
(defun wait-for-sandbox (sandbox) ...)

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

Received: (at 45198) by debbugs.gnu.org; 29 Dec 2020 13:51:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 29 08:51:18 2020
Received: from localhost ([127.0.0.1]:38034 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kuFP8-0004Iv-LW
	for submit <at> debbugs.gnu.org; Tue, 29 Dec 2020 08:51:18 -0500
Received: from mail-oi1-f178.google.com ([209.85.167.178]:39000)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kuFP7-0004Ij-Ev
 for 45198 <at> debbugs.gnu.org; Tue, 29 Dec 2020 08:51:14 -0500
Received: by mail-oi1-f178.google.com with SMTP id w124so14660115oia.6
 for <45198 <at> debbugs.gnu.org>; Tue, 29 Dec 2020 05:51:13 -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=dRtJ5xcdlr8vEeSUA4T/X3KN8A8rwGIv+LQq8MsKmXs=;
 b=vIBGxfXOo2bk3Mo2BItgFeOHenEWzE+9eSSurZ5JM4oqxGw1HGkin4fXcJmtmfTgLC
 YZPL9VwVmkcrIZu0ofbm0/xvmCZz/O6aMF2uh+xScAHESFSnEbxKFP58BukZi/2qHrzv
 DNet01RBhwgqaioeE4n/VbBj6QmaWr567ElLKZlFww00T3SHCPXMpE9Xt0KUWZLtu0v1
 6IF6ptBQEEsMBeuoeEzj9Bk4ebmtwfP0nRHsxQ/SdesGF+pfyvTWnmRmLR5O+tnRKfd6
 hYJI1WR8MMgmYkxuQhOmw2tRyMT6cewbLkZZGlI/I3DmwHr+xGMe5up0TFv5HjsF+4/a
 u5JQ==
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=dRtJ5xcdlr8vEeSUA4T/X3KN8A8rwGIv+LQq8MsKmXs=;
 b=rP1C+zfvPbVI6h2SRhrVc6BZ1zo/wyCA2PTnpY6qkARO4sf5+u5WM5IaPpVQAX8NY6
 FmHs2aF4I5uX2LI8zN+n8DRqDyvNn+MCMtkOincP+ffKm+onZ091BIMhGz8xntjjs5dX
 gf0WaZzoyVYqVPS2xNbWi1zU/d9c5BhjZZZF/wltHMmVnITqOLOuZiZvtJhcHJBPBBE6
 3y9qm75gJiYTvs0tw23vP+YygF79UrPVrYJz6RK5+jYokH+iUk2vvKQUdWTcpEe0xjB5
 XzU/XvZDZxeehixbC6lEiumnlxi5sRq8KrgILW8NfUWKXZnuZI3h/5uZPBlqU2brmfKS
 NOtQ==
X-Gm-Message-State: AOAM533bdhRYtn6mmiCVt9amroesMKphwGg4vsxNsKKMdr171Ozxgs9p
 b5Mc7oc1hY1Ysgq5rDzW31J5mK0xQbwFQydWeTM=
X-Google-Smtp-Source: ABdhPJzC9pU0RuVMlodG8YYB65WGR6qB8XwS71/ZHOxcfO8qEF6f9CgamFIwlMqSYRWKiBQOnjMGLhSYooOSte8qBkM=
X-Received: by 2002:aca:3a02:: with SMTP id h2mr2226685oia.65.1609249867655;
 Tue, 29 Dec 2020 05:51:07 -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>
In-Reply-To: <CAArVCkREr5S=k42mXhW8dMzAtmiv7AG8m5yTSFZ72Bey14=9tw@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 29 Dec 2020 14:50:56 +0100
Message-ID: <CAArVCkR=BwguqGBQFO5pjYJZOmHTX-RJGKmUL9Bon-F1fUNSWQ@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Stefan Monnier <monnier@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,
 =?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 Sa., 19. Dez. 2020 um 23:22 Uhr schrieb Philipp Stephani
<p.stephani2@HIDDEN>:
>
> 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 nee=
ds
> > > > to install a mount namespace that only allows read access to Emacs'=
s
> > > > installation directory plus any input file and write access to know=
n
> > > > output files, and enable syscall filters that forbid everything exc=
ept
> > > > 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.

I've pushed a modified version of these two patches onto the
scratch/seccomp branch. It would be great if someone could test
whether the Windows build still works after that, thanks!

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

Received: (at 45198) by debbugs.gnu.org; 28 Dec 2020 08:23:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 28 03:23:20 2020
Received: from localhost ([127.0.0.1]:34169 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ktnoG-0003Tc-0v
	for submit <at> debbugs.gnu.org; Mon, 28 Dec 2020 03:23:20 -0500
Received: from mail-pj1-f51.google.com ([209.85.216.51]:53459)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1ktnoE-0003TP-3s
 for 45198 <at> debbugs.gnu.org; Mon, 28 Dec 2020 03:23:18 -0500
Received: by mail-pj1-f51.google.com with SMTP id iq13so5594186pjb.3
 for <45198 <at> debbugs.gnu.org>; Mon, 28 Dec 2020 00:23:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:in-reply-to:references:mime-version:date:message-id:subject:to
 :cc; bh=vSu2VNT0JOo5IGChklOF0uxyXC9LCUwzIlixXfRQCWQ=;
 b=bQ8TWfRCVAt5sr4iA5tuYTMlHEFiH6rbQxugviOQ89XFsidMjZFUA66APREWbbpFfG
 YMzZFlInLcFE49OZk2+3Ij31NoMIYhtylt5OFo554iRPmPvD/6t0gxjAnCxQN457g2o5
 uj89b9stz+fkVyZ39oFxYb9k78xAkQU6186xQVbOiQlLtIdokuwjeVd932zP9mBCSP0K
 tTlehBU513cKe1eP2FRMdFP9wHSHOoupyC39gD4UtiRsRh+lUDx7MmpY4B4IK6kH+cSx
 gNakcvOkPZbRQlcI5yCZx2oc8zUrW4XLEGn9tF1BELMQyZfroncfpBII3jpBzWA+/J+K
 YjgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:in-reply-to:references:mime-version:date
 :message-id:subject:to:cc;
 bh=vSu2VNT0JOo5IGChklOF0uxyXC9LCUwzIlixXfRQCWQ=;
 b=Dxdk4Lm/zu7owXuhKvqElPjjGAuURG8xZqDtfvacLw4BXroqt2eiYEBtPH52zN//nZ
 LHb10uJLh3Sg/ON2ausxOQAbBjYz3rNY2R++M1o40cp7cN388dOLlJn4VWb20QzNJc8c
 p7Ra+BphLynKPyBQKXHooSHRtXS85yamDtoxRMcnIc7DTSqUKcaPKD306oS8f3W1yM+K
 1GGWS2hwSsUlv0a7KubZ/+cvzmK6t8qcQgr7PdJHPS0nmz3a1bR7syX3nJfID3Rhxhw7
 1v6mCpVvKcbNQRCUlqH1M8jKfTmJPcmWkvIEYjWn0mqJuusghTpIq9jUBhLOnwR+OX1E
 SSuQ==
X-Gm-Message-State: AOAM530O3jeBlcoiD2unB/nQwr5HpQibgreQZsk129daj4c03f/swbgR
 rApRayGUsNa/23OSe3jMKA6+V5NfIvUhC9Bm36E=
X-Google-Smtp-Source: ABdhPJxPfmow9VXcIaOgsK9+98ud2IP2KwpDdSYFd0HYQLBOjaX+7ZzALbp8RF1LmVTxWfoW9qzopKhpoADYk6XQv8w=
X-Received: by 2002:a17:90b:100e:: with SMTP id
 gm14mr19977084pjb.179.1609143792190; 
 Mon, 28 Dec 2020 00:23:12 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Mon, 28 Dec 2020 09:23:11 +0100
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <CAArVCkST2aCAa3a3YbNZEpysek0HrwPDsVDBRtt4=NSYXFObRQ@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>
 <CAArVCkST2aCAa3a3YbNZEpysek0HrwPDsVDBRtt4=NSYXFObRQ@HIDDEN>
MIME-Version: 1.0
Date: Mon, 28 Dec 2020 09:23:11 +0100
Message-ID: <CADwFkm=Jjx3EnF6SYYNr=hFFLWuL=ZFeuMVhyOprbufydN9Dkg@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
To: Philipp Stephani <p.stephani2@HIDDEN>,
 =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= <mattiase@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.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: -1.0 (-)

Philipp Stephani <p.stephani2@HIDDEN> writes:

> I agree, but we should use the time until Emacs 28 gets released to
> gain experience with the API as well, so we should design the API
> rather sooner than later, because once Emacs 28 is released, we can't
> change it any more in incompatible ways.

IMO, we could release it as an experimental feature and prominently
announce that API changes might happen between major versions of Emacs.
That would give us room to make even backward-incompatible changes,
if/when necessary.

I don't necessarily advocate this; I only want to point out that this is
an option.

(Of course, this would not preclude trying to make it as stable as
possible before Emacs 28.)

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

Received: (at 45198) by debbugs.gnu.org; 22 Dec 2020 14:43:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 22 09:43:39 2020
Received: from localhost ([127.0.0.1]:49311 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1krit0-0000A5-Rq
	for submit <at> debbugs.gnu.org; Tue, 22 Dec 2020 09:43:39 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37510)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1krisy-00009l-EP
 for 45198 <at> debbugs.gnu.org; Tue, 22 Dec 2020 09:43:38 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D66D880A63;
 Tue, 22 Dec 2020 09:43:30 -0500 (EST)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5EDC68063C;
 Tue, 22 Dec 2020 09:43:29 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1608648209;
 bh=DFxlCzTKXbvOhjZ7LePVl3XPd3QSnfpkwPrnJTfMV50=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=DQLbIax+GaUe+VrZaAlT+Mq4BpVz9p9IzUNxyl9pp3e8l9sbvF577J5NBq1LZCnR4
 XDk8qqV13vkBbmqaJeTPOV1xUwe21AQb49c+E10T9/Jkv/gWql6ZZN7QjAt4CmpQzj
 LrjzRWb36m38Et4f2XRRutq7O1BOzlVTL+HLWgyxzLyKfVp6S9KE8UWNt7oEFY7IJt
 nhTPVKWxnGUS7V7E4RUt9xDyy0cLcQT5jaIvcEY6MkTCkbbzzYxGbnODOtHhojqglB
 aDCjH6RhtsRiJR97lsnhL0LbEepcsgj74SRBaKO6McK6OfUq9f9bXuykLKJOVfKjK/
 sgUSY1MEyyQBw==
Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2092D1203CA;
 Tue, 22 Dec 2020 09:43:29 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Message-ID: <jwv8s9p6gxu.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>
 <jwvczz5mlr6.fsf-monnier+emacs@HIDDEN>
 <CAArVCkTLyGNXyaC2QAoU4TM9+VxeWPEG5gOWLCGzbHC9cR+udg@HIDDEN>
 <CAArVCkQF2=Yf2+vqMiM4Zo2Ah7M4Lyb9t1YnE2ujMi5467_uVA@HIDDEN>
Date: Tue, 22 Dec 2020 09:43:28 -0500
In-Reply-To: <CAArVCkQF2=Yf2+vqMiM4Zo2Ah7M4Lyb9t1YnE2ujMi5467_uVA@HIDDEN>
 (Philipp Stephani's message of "Tue, 22 Dec 2020 11:57: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.072 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 (---)

> Such a state is crucial because the subprocesses will want to
> read the entire input before sending output, which isn't possible if

I wouldn't presume this.  If/when such a thing is needed, it's probably
easier to pass the input via a temp file.  E.g. that's what
`elisp-flymake-byte-compile` does.


        Stefan

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

Received: (at 45198) by debbugs.gnu.org; 22 Dec 2020 11:12:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 22 06:12:24 2020
Received: from localhost ([127.0.0.1]:49032 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1krfaa-0006MB-Eq
	for submit <at> debbugs.gnu.org; Tue, 22 Dec 2020 06:12:24 -0500
Received: from mail-ot1-f42.google.com ([209.85.210.42]:34670)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1krfaW-0006Lq-Gr
 for 45198 <at> debbugs.gnu.org; Tue, 22 Dec 2020 06:12:22 -0500
Received: by mail-ot1-f42.google.com with SMTP id a109so11583710otc.1
 for <45198 <at> debbugs.gnu.org>; Tue, 22 Dec 2020 03:12:20 -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=uMu4RWCq/2VYXQGL7aN+8o8bQtqwa3q5PRJzTotei48=;
 b=DRLJoCUQZLY2IwA8+8IJM5nmF9DxtWnLvXbb4Wxam+3x/PvvtxBQzCT1r+Hiq0VBZE
 Jc8X9m/vOZxaTWsQCOXkcJP7+UJ33I0lYBxBFJVxZhPCJR2tgg/5VqrHHAYA0ZYoLD9f
 /NjQqAG2bMDNpx89W5ie/CKGWNfcauE4oYP9UTykv6M2gCnGz1TaDogLqow+Tor5BFI+
 t5TuN8h26m7nw9jD9KI3gtaCHJzASgUhkF97FUMkd3+qrcxqwySPlyPCBaINNpMe23Uw
 HuGqInxHQsMipYdsS6dTHl5It+pG7TqGEn8jw8JsbMWziTwanIp2c2j8yREX9BQOC5gH
 f0lg==
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=uMu4RWCq/2VYXQGL7aN+8o8bQtqwa3q5PRJzTotei48=;
 b=VGptvT5/eWi4jml5YT2XiJdQLb5TGSz1G856NuzyGgWTrwpw8+ky63nvV3AagOodS2
 1sCG/TGaS3fpmSur5urV7bTN15BfxedKjqUULRrFsiT4RjpZXHELpZX5HTsdYqlaznJK
 d6g3Fw5Yhn1jpnAdQNQPFn5ANBrFqY4KwpcpCPW/KBGk1Q/ofMaB3q3TP8q5fBg+ufGu
 +K677SecMUE+8pn2j7ChYKt3WxIzuiPg6rqCQPVWSgo6QETHXi+ifxFRw2T2gUhQC/MY
 8sT+aAuQ41imkZISlYbNWvdCnvj8F+MwcOgqBzrQ4i/SSs0/+2dQaBBKrgHopu/fQNHH
 Ew+w==
X-Gm-Message-State: AOAM5304bU81v8hKsITe5h/SMDGA9p3Nlndf2sAe11/w99hEfNDnlU+1
 /hvGHJOo+Fyu4CGS3MHiMlELHYirhKnCQZNtGe4=
X-Google-Smtp-Source: ABdhPJyzUi0Mv9T8bAyNRekCn5T8irp7qot59Q58Ra3RbWydP31Cj9LfNhcj/UCwvg08iQAAL8wXcp3tzoQsxc4UjTE=
X-Received: by 2002:a9d:72c4:: with SMTP id d4mr15718178otk.149.1608635534719; 
 Tue, 22 Dec 2020 03:12:14 -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>
In-Reply-To: <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 22 Dec 2020 12:12:03 +0100
Message-ID: <CAArVCkST2aCAa3a3YbNZEpysek0HrwPDsVDBRtt4=NSYXFObRQ@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 Sa., 19. Dez. 2020 um 18:19 Uhr schrieb Mattias Engdeg=C3=A5rd <mattiase=
@acm.org>:
>
> 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 r=
egardless of how good programmers we think we are.
> Flymake would be a natural user, but it must cope with our own demands fi=
rst.

I agree, but we should use the time until Emacs 28 gets released to
gain experience with the API as well, so we should design the API
rather sooner than later, because once Emacs 28 is released, we can't
change it any more in incompatible ways.

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

Yes, we should aim for a low false-positive rate, but it doesn't have
to be zero.
As I said, the false-positive rate (or rather, false-discovery rate)
for C currently is often 100%, so maybe we should start with that
first.

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

Received: (at 45198) by debbugs.gnu.org; 22 Dec 2020 10:58:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 22 05:58:12 2020
Received: from localhost ([127.0.0.1]:49017 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1krfMq-0005w2-NH
	for submit <at> debbugs.gnu.org; Tue, 22 Dec 2020 05:58:12 -0500
Received: from mail-oi1-f180.google.com ([209.85.167.180]:37178)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1krfMl-0005vk-RV
 for 45198 <at> debbugs.gnu.org; Tue, 22 Dec 2020 05:58:10 -0500
Received: by mail-oi1-f180.google.com with SMTP id l207so14372819oib.4
 for <45198 <at> debbugs.gnu.org>; Tue, 22 Dec 2020 02:58: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=xrVTw71WVVwbQhhSXf/INk8bDBDughgLQpmEr7GfEOI=;
 b=TCgsqJWvaUtT0y8gMNSgwcPT6LuvOouWY3HJP3cRgpkddN12Jnx7zad+6Pgwnvr2RT
 JKPF5hSgLyhTOmuf/hlUVkvuDKRhCvwiS5JFy1FgDce0Ex9Kv9cdlwL0wjvrHdHAioYo
 9hJqRhWh/+IrEi0M5N2QDqP/bvGwWQbKNENPVgfMrZXyEnTaxUzq6a3us+XmaGbkct+K
 V1MpoOCWf+d0aqpuiHNOkwK56o7fziVaV6ibBvspNRt+PQlKwRn6SeLRvmMFiY9rrDQV
 JnVifdRw/7Nm+tApdKykAoLEPsE8E4JsCJHIHT+NcM5DM4NA9GHrgsj/07t2S8I8kx+E
 z60w==
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=xrVTw71WVVwbQhhSXf/INk8bDBDughgLQpmEr7GfEOI=;
 b=cUb4W2XU4geiK6Lddx7Ig7ei6J9CWz37r+AZRsIHBmYbehMqyz5YWNS9tK/B9ocn5Y
 qAiv2Pg6D+pff+dS4rVPUbxnb3Tyum9chNDg/x4geahMXc01yZoFOLqQCT9v2uNjvffn
 kw7C9TbUcIjCCJrKrdRN2uqkOZpflPqI4EOH48mU6DP0wc9EcgO4cuYKPL046cZHMLk7
 B+zaqG4NTZgNOyqcHkPvmCllRBLf31beQCxB4ZA3gs4TEccepWf7vRI3pU7vivdJO0ei
 Ju0Hm6Sb1TlHQSiLQ9ZsYxr38DvB1U0qM5uypXTDcuMZ+NO3n7sObarLXba7Ng6mtupY
 Ax9A==
X-Gm-Message-State: AOAM532+yUY2FvepJddgAB507UPEGoRj10soKJZ5pNVm5zMYuYdQ62YR
 GLiTeXrRbBZza4m3YzYQ1J2RVeAOS5Qpov54Yxc=
X-Google-Smtp-Source: ABdhPJwwnWTk8V7qbOKyj1LkZmDpF0S3X1jCx978LwaudUKIomzsmxKjuzOUo+kdIELEyhY8Dk7bJ2/1aOp+qonQ4Ec=
X-Received: by 2002:aca:3a02:: with SMTP id h2mr13564172oia.65.1608634681911; 
 Tue, 22 Dec 2020 02:58:01 -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>
 <CAArVCkTLyGNXyaC2QAoU4TM9+VxeWPEG5gOWLCGzbHC9cR+udg@HIDDEN>
In-Reply-To: <CAArVCkTLyGNXyaC2QAoU4TM9+VxeWPEG5gOWLCGzbHC9cR+udg@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 22 Dec 2020 11:57:50 +0100
Message-ID: <CAArVCkQF2=Yf2+vqMiM4Zo2Ah7M4Lyb9t1YnE2ujMi5467_uVA@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 13:28 Uhr schrieb Philipp Stephani
<p.stephani2@HIDDEN>:
>
> > 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.

I've played around with this a bit (both with the pipe pair and with
the socketpair approach), but one issue is that Emacs doesn't know
about half-closed processes (that you can only write to, but not read
from). Such a state is crucial because the subprocesses will want to
read the entire input before sending output, which isn't possible if
the output gets closed after EOF from the input (and that's what
wait_reading_process_output does for both pipes and sockets). So we'd
need to introduce the 'half-closed' process state first, which
requires somewhat larger changes to Emacs's process design and
interface.

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

Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 18:39:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 20 13:39:43 2020
Received: from localhost ([127.0.0.1]:45610 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kr3cN-0001Q6-6t
	for submit <at> debbugs.gnu.org; Sun, 20 Dec 2020 13:39:43 -0500
Received: from mail-ot1-f43.google.com ([209.85.210.43]:46818)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1kr3cH-0001Pq-Sk
 for 45198 <at> debbugs.gnu.org; Sun, 20 Dec 2020 13:39:42 -0500
Received: by mail-ot1-f43.google.com with SMTP id w3so6916182otp.13
 for <45198 <at> debbugs.gnu.org>; Sun, 20 Dec 2020 10:39:37 -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=ZcRftGnIlfunjaKxdi6yc/NY2U8xG2ixEJYfySmUmvc=;
 b=AJISIYB2bI8LFyMVaWU0rT9pDW9kEFnl0h061Vvf0mpvwuJ4ydAi4tTD3t/fmF81yQ
 o5pN52Io/PUifgAL4pnXrZLIp6ex/O1NGMHVGWZxZLn9wH4qwvl/BOMDxMh4sxHK2v0Z
 yO7vCZVA8+5kIHO7/6PQ7vRWyhb4adUZxYD/1vd/UjlydxXD/duoe27FNv1n7BHm+DOv
 g0cBwlPFVP7kpWRmD3sAOPWinq95ORXC3u9Cjyn7NraRDxRxFxycoakKZYbCwhYqxC4+
 ELlhy8MmKmNP2Jtb1oaEaBAX0DfyNmRKOPlB0/BcHPtFVqxypKvWONPxvxHVqVJmsWG2
 GlvQ==
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=ZcRftGnIlfunjaKxdi6yc/NY2U8xG2ixEJYfySmUmvc=;
 b=is7jweSjflRdndyZoRWFxdcLDOTkh1rcBtQ3Lfn8YRPo6N/D7lYFfNYUHjniCbhbF/
 JNyvCa36oIz6/HGl/+bScCepTQVWgsHfl6Y5ZxzlT3Zd+xIbKDiY+M1iKsRl4K/QTLD6
 QDxB2I+09HrE8Mq00rdRJFauNAmg5r+OoxoyVihpUgafpwFxZDzwTyuXdeuYtYJmex1d
 /OQCGK+iFF4WdjrM1ocdZyJ/Ez8Uq1qcSUP8gMl+3wY+Qq0gs7Smjwi/TBHppkmm7RIm
 l9IcIMLfKpuy8UNvsJwRQ1pICWmkcOAunRRy3R/G8qn0lb9+xcg/DFZEBiDLlYni/tjA
 5Aww==
X-Gm-Message-State: AOAM531xGcRc5OxfJFfjWWtJS/tjOMnua93fQZIjgIcFFeonWnj1sgtb
 bwq5Q7YSKxujTYXm5fvZkyMs7ESiPHCmkgNAFYM=
X-Google-Smtp-Source: ABdhPJzDtIJUfdavPEN4JLLnlB3AhKTm2eOPm/fQR7XJ2cWjyjr/bddF4INNUPzpGQSCmalZBeEcD/eM06lfBA917AE=
X-Received: by 2002:a05:6830:3106:: with SMTP id
 b6mr9317851ots.36.1608489571953; 
 Sun, 20 Dec 2020 10:39:31 -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>
 <CAArVCkS3GfC-JwU=F_WHUon7KYfqdLRjG9dHxm_tVwJEOArKPQ@HIDDEN>
 <83pn34s551.fsf@HIDDEN>
In-Reply-To: <83pn34s551.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Sun, 20 Dec 2020 19:39:20 +0100
Message-ID: <CAArVCkTgpDutNs1SBTHuy1hJmm0LJOpo6USidhL-juer11tXJA@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 19:29 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
>
> > From: Philipp Stephani <p.stephani2@HIDDEN>
> > Date: Sun, 20 Dec 2020 19:14:07 +0100
> > Cc: Stefan Monnier <monnier@HIDDEN>, Bastien <bzg@HIDDEN>, 4=
5198 <at> debbugs.gnu.org,
> >       Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
> >
> > Am So., 20. Dez. 2020 um 16:10 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>=
:
> > >
> > > > +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.
>
> What about the --seccomp command-line switch to Emacs: isn't its
> support a feature that should be called out?

OK, that's in a different patch though. I'll add a feature for it in
that patch then.

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

Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 18:29:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 20 13:29:42 2020
Received: from localhost ([127.0.0.1]:45603 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kr3Sg-0001BP-6x
	for submit <at> debbugs.gnu.org; Sun, 20 Dec 2020 13:29:42 -0500
Received: from eggs.gnu.org ([209.51.188.92]:43736)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kr3Se-0001BB-2e
 for 45198 <at> debbugs.gnu.org; Sun, 20 Dec 2020 13:29:41 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:50473)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kr3SY-0003G9-Qk; Sun, 20 Dec 2020 13:29:34 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2114
 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 1kr3SW-0005a2-GM; Sun, 20 Dec 2020 13:29:34 -0500
Date: Sun, 20 Dec 2020 20:29:14 +0200
Message-Id: <83pn34s551.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <CAArVCkS3GfC-JwU=F_WHUon7KYfqdLRjG9dHxm_tVwJEOArKPQ@HIDDEN>
 (message from Philipp Stephani on Sun, 20 Dec 2020 19:14:07 +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>
 <831rfktsxp.fsf@HIDDEN>
 <CAArVCkS3GfC-JwU=F_WHUon7KYfqdLRjG9dHxm_tVwJEOArKPQ@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: Sun, 20 Dec 2020 19:14:07 +0100
> Cc: Stefan Monnier <monnier@HIDDEN>, Bastien <bzg@HIDDEN>, 45198 <at> debbugs.gnu.org, 
> 	João Távora <joaotavora@HIDDEN>
> 
> Am So., 20. Dez. 2020 um 16:10 Uhr schrieb Eli Zaretskii <eliz@HIDDEN>:
> >
> > > +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.
> 
> 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.

What about the --seccomp command-line switch to Emacs: isn't its
support a feature that should be called out?

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.

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.

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

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.

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

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.

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.

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

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.

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

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

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

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.

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

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

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

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

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.

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)

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.

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

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.

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.

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

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

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.

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

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.

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

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

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

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.

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

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.

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.

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

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.

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

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)

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.

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

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>,
>  João Távora <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.

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)