proposal: syscall: Support linux namespace fd's in SysProcAttr

[cpuguy83]

I've been working on a package to help work on Linux namespaces (https://github.com/cpuguy83/gonso).
One of the things I'd like to be able to do is, as a library author, enable users of the library to run an executable in a given set of namespaces.
Today this would require the user of the library to have a helper process join those namespaces before executing the command.
In the library I could setup a thread with the namespaces and run the command but this doesn't really work with exec.Cmd since that can spin up its own goroutines not locked to the current thread.

I've also looked at creating essentially my own bad copy of exec.Cmd that would allow me to do this but ideally this would just work with the real exec.Cmd

What I propose is to add something like:

diff --git a/src/syscall/exec_linux.go b/src/syscall/exec_linux.go
index b61b51dff1..fd27257461 100644
--- a/src/syscall/exec_linux.go
+++ b/src/syscall/exec_linux.go
@@ -59,6 +59,11 @@ type SysProcIDMap struct {
 	Size        int // Size.
 }

+type LinuxNamespace struct {
+	Fd   int // Namespace file descriptor
+	Kind int // e.g. CLONE_NEWNS
+}
+
 type SysProcAttr struct {
 	Chroot     string      // Chroot.
 	Credential *Credential // Credential.
@@ -98,9 +103,10 @@ type SysProcAttr struct {
 	// This parameter is no-op if GidMappings == nil. Otherwise for unprivileged
 	// users this should be set to false for mappings work.
 	GidMappingsEnableSetgroups bool
-	AmbientCaps                []uintptr // Ambient capabilities (Linux only)
-	UseCgroupFD                bool      // Whether to make use of the CgroupFD field.
-	CgroupFD                   int       // File descriptor of a cgroup to put the new process into.
+	AmbientCaps                []uintptr        // Ambient capabilities (Linux only)
+	UseCgroupFD                bool             // Whether to make use of the CgroupFD field.
+	CgroupFD                   int              // File descriptor of a cgroup to put the new process into.
+	Namespaces                 []LinuxNamespace // Namespaces to join before exec
 }

 var (

I think this is a more generally useful addition since it allows anyone to set which namepsaces they want the command to run in without having to resort to using external tooling (such as nsenter) or re-exec/cgo init hacks.

[ianlancetaylor]

CC @kolyshkin @avagin

[kolyshkin]

I like the overall idea, but perhaps some higher-level way of specifying the namespaces is better.

Say something like

Namespaces []string

where each element is in the form "type:path". The type is one of "cgroup", "ipc", "mnt", "net", "pid", "user", "uts", and the path is an arbitrary filesystem path to open.

What the code would do is map those types to CLONE_XXX flags, open the files, and then call setns(2) for each one.

1. Using a string instead of a CLONE_FLAG will make it slightly more portable (say we won't have to export more CLONE_XXX flags from the deprecated syscall package)
2. I am not quite sure about using path vs file descriptor; one thing I can think of is path is a superset of fd, given than one can use /proc/self/fd/N to refer to fd N.

[cpuguy83]

@kolyshkin I think that could work, though it is definitely different from other things, such as CgroupFD

I'm fine either way.

[cpuguy83]

@kolyshkin Is there any issue with having to do the parsing on that string in the syscall package?

[cpuguy83]

Is there something we can do to move this discussion forward? Does this need to be in the active discussion list before a change should be submitted? /cc @rsc

[ianlancetaylor]

You can send in a change any time but it won't be approved and submitted until this proposal is accepted. In this case actually I think seeing the code would help, as I don't really understand the proposal myself. Thanks.

I see there is a suggestion above for a different approach, and that doesn't seem to be settled. We aim to get consensus on proposals. @kolyshkin any more thoughts on the approach? Thanks.

[cpuguy83]

I opened #59018 for this.

[gopherbot]

Change https://go.dev/cl/476095 mentions this issue: syscall: add support for setns after fork