Add command-pid member to --json-status-fd

[WGH-]

In cases where bwrap runs its own additional PID 1 process (e.g. --unshare-pid), child-pid is the PID of that process, not the PID of the user-specified COMMAND.

This is inconvenient as the user might want to send e.g. SIGTERM to the command to give it a chance to exit gracefully.

Example:

$ ./bwrap --json-status-fd 2 -- /bin/true
{ "child-pid": 2779366, "mnt-namespace": 4026538517 }
{ "command-pid": 2779366 }

$ ./bwrap --json-status-fd 2 --unshare-pid -- /bin/true
{ "child-pid": 2779372, "mnt-namespace": 4026538517, "pid-namespace": 4026538518 }
{ "command-pid": 2779373 }

Closes #553

[WGH-]

Note that unlike child-pid this is currently impossible to use while being immune to PID reuse.

For child-pid you can do something like this:

pid = receive_pid_from_json_status_fd()
pidfd = pidfd_open(fd)
# if block_fd is not closed, then child-pid certainly was alive at the time of pidfd_open() call
if closed(block_fd):
    close(pidfd)
    return None
return pidfd

Unless I'm missing some simple solution, we'll have to introduce another block_fd-like fd that would be leaked to the COMMAND process (and even then COMMAND may close it early, making the code inadvertently fail).

[WGH-]

Heh. I'll rebase and fix conflicts in a day or so.

[WGH-]

Rebased

[smcv]

This will make the uppermost process (the monitor process, outside the sandbox) block until the final process sends its pid. And, if the child process (reported as child-pid) fails for any reason, then read_pid_from_socket() will fail with a fatal error, preventing monitor_child() from relaying the true exit status of the child.

I think it would be better to monitor command_pid_sockets[0] in monitor_child(), and use non-blocking I/O for that, so that we output the information when we have it, but we don't wait for it.

[smcv]

currently impossible to use while being immune to PID reuse

Yeah, that's quite a serious limitation. It doesn't necessarily make this feature addition entirely useless, but it's certainly something that users of this feature would need to be careful about.

This is inconvenient as the user might want to send e.g. SIGTERM to the command to give it a chance to exit gracefully

I think the better way to solve this particular use-case would be a fixed version of #586: teach the top-level bwrap monitor process to be able to forward signals like SIGTERM to the sandbox init process (already done in #586), and then teach the sandbox init process (do_init()), if used, to forward those same signals into the final process that exec'd the user-specified COMMAND.

That way, instead of sending your signals to the child-pid (possibly subject to PID reuse bugs) or to the command-pid (definitely subject to PID reuse bugs), you could send them to the top-level bwrap monitor, which would forward them to the correct child process internally.

[WGH-]

Hmmm, yes, I agree. This is getting both complicated and subtly buggy. Perhaps, we shouldn't move forward with this approach.

I suppose the right way to do this would be to make bwrap send a pidfd file descriptor (pidfd_open) over a UNIX socket. That would also be somewhat complicated, and I think completely unusable from shell scripts, but at least it would be free of reuse bugs.