[Feature request] Pass file descriptors in std::comand::Command

[axelkar]

I was reading bytecodealliance/rustix#100 (comment) and remembered that Rust's std doesn't have a way to pass (non-stdio) file descriptors to child processes.

I was wondering, could a way to do that be added into std::command::Command?

I also propose these properties:

• Know the FD numbers before spawning, e.g. for the LISTEN_FDS environment variable. Maybe the user provides the FD numbers and the library uses dup2?
• close_fds=True (is this applicable? not sure how it's implemented in Python)

Prior work:

• cap_std_ext::CapStdExtCommandExt
• std::process::Command and I/O safety bytecodealliance/rustix#100
• @sunfishcode @cgwalters

[the8472]

You may want to file an ACP, or several.

But this topic isn't trivial across platforms.

• I/O safety forbids the "pass FD via env var" pattern (e.g., jobserver) #116059
• #t-libs-api/api-changes > Extra FDs in CommandExt
• #t-infra > CI images local build times @ 💬
• Ability to stop child process from Inheriting Handles libs-team#264

[axelkar]

Thanks for the links!

I didn't see the issue about receiving FDs with exec+environment variables being I/O unsafe in Rust. So it's unsafe just because you're creating OwnedFds with FromRawFd, which can't statically prove that it's the only owned instance of the FD? Wouldn't BorrowedFd<'static> work? I guess you wouldn't be able to use File or TcpStream or similar with that.

I'll try file ACPs.

[cgwalters]

I have a simple version of this here https://docs.rs/cap-std-ext/latest/cap_std_ext/cmdext/trait.CapStdExtCommandExt.html

But I agree that encouraging a pattern that's at least robust to child process inheritance would be good.

[the8472]

The LISTEN_FDS protocol allows C libraries to close them at will.

The file descriptors passed this way may be closed at will by the processes receiving them: it is up to the processes themselves to close them after use or whether to leave them open until the process exits (in which case the kernel closes them automatically).

This doesn't compose well.

So it's unsafe just because you're creating OwnedFds with FromRawFd, which can't statically prove that it's the only owned instance of the FD?

No, it's also because the environment variables instruct child processes to touch some FD numbers without having a mechanism to ensure that the children are not touching the wrong FDs. If the variables and the file descriptors go out of sync in process inheritance that can be unsound, just like the jobserver protocol.