ACP: std::os::unix::process::CommandExt::chroot

[joshtriplett]

Proposal

Problem statement

We provide std::os::unix::fs::chroot to provide a safe interface to chroot. However, we don't provide any safe way to run a child process in a chroot.

Solution sketch

// In `std::os::unix::process`, along with corresponding `impl`:
trait CommandExt {
    /// Set the root of the child process. This calls `chroot` in the child process before executing
    /// the command.
    ///
    /// This happens before changing to the directory specified with `Command::current_dir`, and
    /// that directory will be relative to the new root. If no directory has been specified with
    /// `Command::current_dir`, this will set the directory to `/`, to avoid leaving the current
    /// directory outside the chroot.
    fn chroot<P: AsRef<Path>>(&mut self, dir: P) -> &mut process::Command;
}

Alternatives

The proposed interface automatically sets the current directory for the child process if it isn't yet set, to avoid ending up in the situation where the current directory is outside the chroot. We could, instead, leave the current directory untouched, and leave the user responsible for calling current_dir themselves. However, I think it's worth not exposing the weird situation to users. If users really want to end up in that weird situation (e.g. because they're trying to write code that busts out of a chroot) they can make direct syscalls.

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[joshtriplett]

Implementation at rust-lang/rust#137759 .