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: Sun, 20 Dec 2020 13:28:51 +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="29464"; 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 Sun Dec 20 13:30:39 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 1kqxrC-0007ck-T0
for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Dec 2020 13:30:38 +0100
Original-Received: from localhost ([::1]:37612 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1kqxrB-0002mG-TT
for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Dec 2020 07:30:37 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33272)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1kqxqd-0002kR-9Y
for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2020 07:30:07 -0500
Original-Received: from debbugs.gnu.org ([209.51.188.43]:60521)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from )
id 1kqxqd-0003ON-0l
for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2020 07:30:03 -0500
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
(envelope-from ) id 1kqxqc-0000aB-Rm
for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2020 07:30: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: Sun, 20 Dec 2020 12:30: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.16084673502156
(code B ref 45198); Sun, 20 Dec 2020 12:30:02 +0000
Original-Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 12:29:10 +0000
Original-Received: from localhost ([127.0.0.1]:43834 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from )
id 1kqxpm-0000Yi-Dg
for submit@debbugs.gnu.org; Sun, 20 Dec 2020 07:29:10 -0500
Original-Received: from mail-ot1-f44.google.com ([209.85.210.44]:34062)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from ) id 1kqxpl-0000YW-7g
for 45198@debbugs.gnu.org; Sun, 20 Dec 2020 07:29:09 -0500
Original-Received: by mail-ot1-f44.google.com with SMTP id a109so6448512otc.1
for <45198@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)
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:196465
Archived-At:
Am So., 20. Dez. 2020 um 00:17 Uhr schrieb Stefan Monnier
:
>
> >> 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.