Related Issues

• os/exec: Can't use os.Command (with ExtraFiles) that uses /proc/self/fd/<exe fd> as the executable #66654
• syscall: nextfd handling for attr.Files shuffle will clobber files #61751
• proposal: syscall: Support linux namespace fd's in SysProcAttr #56680

Related Code Changes

• syscall: add support to get pidfd from ForkExec on Linux
• syscall: on exec failure, close pidfd
• syscall: document that Exec wraps execve(2)
• [release-branch.go1.12] os: enable the close-on-exec flag for openFdAt

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

CC @neild

It seems that it would make sense to consider this in conjunction with the new os.Root family of functions. For example, perhaps we should support os.(*Root).StartProcess(name string, argv []string, attr *ProcAttr). That suggests that rather than ExecFD we should have DirFD. I think it would have to be something like

    At      bool // use execveat with DirFD and AtFlags
    DirFD   int  // if At is true, dirfd argument to execveat
    AtFlags int  // if At is true, flags argument to execveat

In order to use this we would have to add AT_EMPTY_PATH and AT_SYMLINK_NOFOLLOW to the syscall package.

The execveat behaves like fexecve only when pathname is empty path uintptr(unsafe.Pointer(&empty[0])) and the _AT_EMPTY_PATH is supplied. To support the above use case, the pathname parameter of the syscall need to be adjusted, or controlled by AtFlags.

@criyle I can't tell if you are pointing out a problem or not. The pathname is under program control, along with the fields in SysProcAttr. So if a program wants the equivalent of fexecve, it can pass AT_EMPTY_PATH and an empty path name.

You are right, the user can pass empty string to argv0 directly using your proposed API like

syscall.ForkExec("", argv, &syscall.SysProcAttr{
    At: true, 
    DirFD: fileFD, 
    AtFlags: syscall.AT_EMPTY_PATH
})

It indeed made the implementation more generic to other use cases. Sorry that I remembered the os/exec.Cmd does not accept empty string Path, so I made a false assumption to assume the argv0 is not accepting that either.

I don't understand the point about "fexecve requires mount of /proc system". The example in #66654 seems to be using execve("/proc/self/fd/X", ...) to mimic the behavior of fexecve(X, ...), but I don't see why fexecve itself would require /proc.

If we're adding new API here, it seems like we should do it for all OSs that support the necessary syscalls. FreeBSD at least has fexecve.

os.(*Root).StartProcess(name string, argv []string, attr *ProcAttr) seems reasonable to me. If we do want to support that, perhaps we should also have a way to use it from os/exec.Cmd. Perhaps something like:

package exec

type Cmd struct {
  // ...

  // Root specifies the root the command is relative to.
  //
  // If Root is non-nil, Path is interpreted relative to the root.
  Root *os.Root
}

I'm not sure how Cmd.Root and Cmd.Dir should interact, though.

fexecve requires mount of /proc system

From the fexecve(3) man page, the POSIX's fexecve is implemented via proc system by glibc on systems that does not have execveat syscall, and the two issues I have linked showed that this kind of ancient implementation is not reliable. This proposal is to add support to fexecve using newer system interface execveat if available (kernel >= 3.19). Sorry that I should say "outdated implementation of fexecve requires mount of /proc system" instead of made it so generic.

Rather than a Root field in exec.Cmd, perhaps we could have a new function

// CommandRoot is like CommandContext, but the executable is relative to root.
func CommandRoot(ctx context.Context, root *os.Root, name string, arg ...string) *Cmd

I think that may be a more natural way to describe what we want to execute. It would set the SysProcAttr fields accordingly.

If we do add something, I think it should use fexecve on systems which have it but not execveat. That is: This shouldn't be a Linux-specific feature. (Even if we just add something to syscall, we should think about non-Linux systems.)

My one concern about CommandRoot is whether we need to be able to make Cmd.Dir root-relative, and if so, whether it needs to potentially be a different root than Cmd.Path. That seems like a very specialized need, but all of this is satisfying very specialized needs.

I think that if we take the CommandRoot path then Dir is not relative to the root. That seems like a separate thing.

Of course, we should think about some approach for setting Dir safely, which is a valid concern whether or not the executable is in a root or not. For example, it seems reasonable to run /bin/ls in a user-specified directory that must be within some root.