std::process::Command doesn't follow Unix signal safety in forked child

[ericyoungblut]

Update (2022-12-12): The issue description is outdated, but some problems remain.

These lines from spawn can cause a deadlock. It's wrong to assume that you can lock in the parent and the unlock in the child. Read man 2 fork and man 7 signal-safety on Linux.

    // Whatever happens after the fork is almost for sure going to touch or
    // look at the environment in one way or another (PATH in `execvp` or
    // accessing the `environ` pointer ourselves). Make sure no other thread
    // is accessing the environment when we do the fork itself.
    //
    // Note that as soon as we're done with the fork there's no need to hold
    // a lock any more because the parent won't do anything and the child is
    // in its own process.
    let result = unsafe {
        let _env_lock = sys::os::env_lock();
        cvt(libc::fork())?
    };

Qumulo has a custom thread library which exposes this issue.

[steveklabnik]

Triage: I am not sure that the standard library intends to be fork safe.

[Mark-Simulacrum]

Cc @joshtriplett

We try to make sure std code itself is fork safe, though that may not apply to std APIs (e.g., forking in Cell::update is probably a bad idea).

I am unsure what exactly is a good solution in this case, though.

[RalfJung]

Triage: I am not sure that the standard library intends to be fork safe.

I mean, the operations it provides should be implemented properly. From how I understand this post, using std::process::Command can lead to violating the contract of the underlying APIs by calling something non-async-signal-safe after fork().

We also made before_exec unsafe partially because of signal safety concerns.

[RalfJung]

Also it seems like execvp is not signal-safe (which is quite surprising, as fork+exec is such a standard operation), so the cases where Command uses that function are also violating POSIX.

[tmiasko]

See #55359 for an approach that doesn't have the issues described here. It also avoids execvp (note that the pull request description isn't up to date with respect to the final version of the code).

Although, it didn't handle the case when PATH was unset, where excevp uses a default search path _CS_PATH, introduced a search path regression, and was subsequently reverted.

[RalfJung]

Oh wow I had already successfully forgotten this...

[RalfJung]

@joshtriplett wrote elsewhere:

To the best of my knowledge, execvp is only considered "not async signal safe" because all functions that read the environment aren't safe against concurrent modifications: if you change PATH concurrently from another thread, you have no guarantees whether it'll use the old PATH, the new, or some combination thereof. execvp is listed as MT-Safe env, meaning "it's multi-thread safe as long as you don't expect environment variables to do any synchronization for you".

However, it is not clear to me how "multi-thread safe" and "signal safe" (aka can-be-used-after-fork) relate.

[joshtriplett]

We also can't rely on any particular safety property of execvp that happens to be true in a particular implementation, since it isn't guaranteed by the standard.