bug#45198: 28.0.50; Sandbox mode

[Philipp Stephani <p.stephani2@gmail.com>]

Am So., 20. Dez. 2020 um 00:17 Uhr schrieb Stefan Monnier
<monnier@iro.umontreal.ca>:
>
> >> 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.