File descriptor leak when spawning new process

[l0kod]

When using an external library and/or FFI bindings, all non-cloexec file descriptors leak to all new processes spawned with Command::spawn().

This was introduced by the I/O reform because the getdtablesize() loop disappeared.

The getdtablesize() loop could be replaced with a walk_dir() through /proc/self/fd when available (cf. #12148 (comment)).

cc #12148
cc #22678
cc #24237
cc rust-lang/rfcs#941

cc @alexcrichton
cc @aturon

[alexcrichton]

This is currently a very intentional part of the design of Command. There's a legitimate use case for having file descriptors inherited across forked processes on Unix (e.g. it's expected behavior), so going out of our way to prevent that from happening isn't in the same spirit as the rest of the I/O bindings of the standard library.

The standard library opens everything with CLOEXEC by default (and will one day provide the ability to not do so), but adding this sort of code on a post-fork would at most be a platform extension and would probably best be done with a "run this block post-fork" option to Command on unix. As such I believe this is an issue for the RFC repo instead of this one, so I'm going to close this issue.

[l0kod]

This sounds like a security issue. A safe API should use an extra_io whitelist like did the previous I/O library.

[alexcrichton]

@l0kod this is not a security issue for the standard library, if it's an issue at all it's an issue with the libraries that are opening file descriptors without CLOEXEC.

[l0kod]

OK, so it's an issue with almost all bindings…

[l0kod]

Is it OK if I create a PR to extend CommandExt for UNIX with something like close_fds_except(&mut, &[AsRawFd])?

[alexcrichton]

We explicitly removed this behavior, so I would probably expect an RFC before a PR.