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.