From mboxrd@z Thu Jan 1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Philipp Stephani
Newsgroups: gmane.emacs.bugs
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Sat, 19 Dec 2020 23:41:50 +0100
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
logging-data="24509"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: Bastien , 45198@debbugs.gnu.org,
=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=
To: Stefan Monnier
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 19 23:43:13 2020
Return-path:
Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org
Original-Received: from lists.gnu.org ([209.51.188.17])
by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92)
(envelope-from )
id 1kqkwS-0006I6-JV
for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Dec 2020 23:43:12 +0100
Original-Received: from localhost ([::1]:40878 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1kqkwR-0004Tu-6D
for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Dec 2020 17:43:11 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46656)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1kqkwI-0004Tk-Uw
for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2020 17:43:03 -0500
Original-Received: from debbugs.gnu.org ([209.51.188.43]:60046)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from )
id 1kqkwI-00079t-7X
for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2020 17:43:02 -0500
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
(envelope-from ) id 1kqkwI-00018t-5K
for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2020 17:43:02 -0500
X-Loop: help-debbugs@gnu.org
Resent-From: Philipp Stephani
Original-Sender: "Debbugs-submit"
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Sat, 19 Dec 2020 22:43:02 +0000
Resent-Message-ID:
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 45198
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
Original-Received: via spool by 45198-submit@debbugs.gnu.org id=B45198.16084177314332
(code B ref 45198); Sat, 19 Dec 2020 22:43:02 +0000
Original-Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 22:42:11 +0000
Original-Received: from localhost ([127.0.0.1]:43359 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from )
id 1kqkvS-00017o-Jg
for submit@debbugs.gnu.org; Sat, 19 Dec 2020 17:42:10 -0500
Original-Received: from mail-ot1-f49.google.com ([209.85.210.49]:37029)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from ) id 1kqkvQ-00017a-0K
for 45198@debbugs.gnu.org; Sat, 19 Dec 2020 17:42:09 -0500
Original-Received: by mail-ot1-f49.google.com with SMTP id o11so5545567ote.4
for <45198@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)
In-Reply-To:
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
X-BeenThere: bug-gnu-emacs@gnu.org
List-Id: "Bug reports for GNU Emacs,
the Swiss army knife of text editors"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org
Original-Sender: "bug-gnu-emacs"
Xref: news.gmane.io gmane.emacs.bugs:196436
Archived-At:
Am Mo., 14. Dez. 2020 um 15:44 Uhr schrieb Stefan Monnier
:
> >> 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.