Support specifying netns (and userns?) file path as well as PID

[AkihiroSuda]

proposed in containers/podman#2897

[sboeuf]

@AkihiroSuda thanks for opening this issue!
I'd like to clarify the way to implement this. Currently the way slirp4netns works, it expects the process id of the container to be provided to know which network namespace needs to be joined.
Here we are talking about adding some flags/options in order to join specific network namespace based on a path and not a process ID.

The question I have is about the way to do this. Do you want to keep backward compatibility about providing a process ID that would be superseded by --netns-path if it is there? Or instead should we simply remove the expectation about the process ID, providing --netns-path and --pid?

[sboeuf]

/cc @amshinde @gabibeyer

[AkihiroSuda]

We need to keep compatibility.

The PID portion should be an empty string when --netns-path is present?

[AkihiroSuda]

cc @giuseppe

[amshinde]

@AkihiroSuda We would need to pass a user namespace path and a mount namespace path as well, if I am not mistaken.

[amshinde]

Just adding details of what was discussed with @giuseppe, from the podman point of view, when running in rootless mode, podman creates a user and mount namespace and calls slirp4netns from the same user+mount namespace. So what podman would need to provide to slirp4netns is the network namespace path.

[gabibeyer]

@AkihiroSuda @giuseppe Would you rather an empty string for PID when --netns-path is passed, or don't allow the PID arg altogether, and only the single TAPNAME argument to be passed?

slirp4netns --netns-path=<PATH> "" <TAPNAME>
slirp4netns --netns-path=<PATH> <TAPNAME>

I'm working on a PR to solve this issue, thank you for the help !

[AkihiroSuda]

I prefer the former one.
cc @giuseppe WDYT?

I think we should also have --userns-path for consistency with PID mode even though it is not needed for Podman.

[giuseppe]

could we reuse the same argument? We can consider it a path if it starts with /

slirp4netns /path/to/the/ns
slirp4netns 1234

what do you think?

[AkihiroSuda]

We can consider it a path if it starts with /

No support for relative path? How to support specifying userns path?

[giuseppe]

No support for relative path? How to support specifying userns path?

I'd expect the path to be mostly specified as /proc/PID/ns/net or /proc/self/ns/net. If we want support for relative path then we could probably use something like:

slirp4netns --netns-path <PATH|PID>

if --netns-path is specified then the first argument is a path, otherwise a pid, or alternatively:

slirp4netns --netns-type=path <PATH|PID>

so we don't have to deal with an empty argument

[rhatdan]

slirp4netns --netns-type=path <PATH|PID>
slirp4netns --netns-type=pid <PATH|PID>
With pid as default works for me.
I would avoid the ambiguity.

[AkihiroSuda]

--netns-type SGTM, but wondering how we can specify userns path, though it is not needed for Podman. maybe just --userns-path=/foo/bar

[sboeuf]

I have one proposal if you really want to make this generic. We could introduce --netns, --userns, and --mntns flags, but also keep the PID through the command line.
By default, slirp4netns would work as it is working right now, which means it would pick all namespaces from the PID, but if one of the additional option is used, it would override the namespace specified by the flag. WDYT?

[amshinde]

I like @sboeuf's proposal to keep the existing pid option and introduce two new options --netns and --userns. These would be used to override, if pid is provided as well, if neither the pid nor the namespace paths are provided, then slirp4netns would error out.

[gabibeyer]

@sboeuf I feel like the only problem with that is what the PID argument would be if --netns-path is passed.

How about a hybrid approach, a 'no-argument' option --use-netns-path that will allow the pid arg to be a path, otherwise it will expect a PID value. The current logic of getting the mount namespace and user namespace from the PID will stay in place. Then an addition of --userns-path=PATH and --mntns-path=PATH can be used to override what the PID finds, as previously suggested.

so something like

slirp4netns --use-netns-path --mntns-path=<PATH> --userns-path=<PATH><PATH> tap0
slirp4netns --mntns-path=<PATH><PID> tap0

if a user doesn't specify a userns-path, or a mntns-path with the --use-netns-path, and they are required within the code, it can error out then.

[AkihiroSuda]

I dont have a strong opinion - UX is out of scope of this repo, but IIUC we dont need the mntns stuff