Hi Richard,
On Sun, 19 Jul 2026 15:03:00 -0500
Richard Lawrence
From: Richard Lawrence
When pasta mode is used to launch an executable (`pasta [COMMAND]`) and that executable accepts inputs in the form of arbitrary file descriptors (such as `bwrap`), then passt should not stand in the way of the parent process handing off those file descriptors to the child process. See bug 204 for additional discussion.
The `pass-fds` option accepts a comma-separated list of file descriptor numbers. `conf_pass_fds()` parses the command line argument, then `isolate_fds()` skips closing the specified fds by calling `close_range()` on the gaps between them.
Additionally, the tap fd is safely relocated to the lowest unused fd number which it at least 3, to avoid accidentally overwriting an existing fd.
Thanks for following up. I haven't had a chance to review this in detail yet, but it looks significantly simpler than v2. While I agree with David that the use case should be clearly mentioned in the commit message (it's not entirely clear to me, either, what advantage you get by letting pasta spawn a somehow isolated process), both you and John seem to have the same use case, which I would take as an indication that there's some actual convenience in this. So, as long as it's harmless and sufficiently secure, I don't really have anything against this (except for the pending comments that need to be addressed). Another thing I've been discussing offline with David was the possibility of making pasta spawn the command before closing other open file descriptors. That would be even simpler, and it should be possible to do so without any race condition (contrary to what I previously thought) as the child process waits anyway on a signal from the parent before proceeding. So we could leave those files (optionally) open in the child process taking care of the execvp(), and close them in the parent before the actual networking setup takes place, and before the command is spawned, making sure pasta itself has no possible access to any accidentally leaked file descriptor (which is the security concern here, we don't really care if the spawned command can access them). I haven't really thought this through but it might be worth a try and satisfy your use case anyway, in a simpler way. If that doesn't work for whatever reason I'm ignoring, let's stick to your approach instead. I'll review your patch within a couple of days in that case. Sorry for the delay. -- Stefano