On Wed, Jul 09, 2025 at 01:54:36AM +0200, Lisa Gnedt via user wrote:
Date: Wed, 9 Jul 2025 01:54:36 +0200 From: Lisa Gnedt
To: Stefano Brivio CC: passt-user@passt.top, Paul Holzinger Subject: Re: Issues when using pasta with bubblewrap List-Id: "For passt users: support, questions and answers" Hi Stefano,
Hi Lisa, I'm back from extended leave and looking at this thread as Stefano suggested.
Thanks for you fast feedback!
On 2025-07-07 18:19, Stefano Brivio wrote:
For context, "this" is: always join the user namespace owning a network namespace.
Yes, exactly.
It looks reasonable (and desirable) to me, but I'm not sure how / why it breaks the --userns parameter.
In the case, where a PID is supplied, it misuses the userns variable and sets it to the path of the network namespace and then always calls the ioctl NS_GET_USERNS to get the owning user namespace. However, the userns variable might also be manually set via the --userns option, whereas we expect users to set this parameter to the path of a user namespace. The ioctl NS_GET_USERNS returns the parent user namespace when a user namespace is given. Therefore, we join the parent user namespace with this patch instead of joining the given user namespace.
We should probably never do this when --netns-only is given (that's Podman's case, for example).
I agree, it does not make sense to join a user namespace, when a user explicitly only wants to join the network namespace.
So.. I think this discussion is missing a crucial point: In order to operate, pasta *must* end up in the userns owning the guest's netns. --userns and --netns-only aren't exceptions to that, they're just different ways of locating the correct userns. In PID/--netns mode, I think NS_GET_USERNS makes --userns entirely obsolete. No need to have the user tell us the right userns when we have a reliable way to discover it. It also makes --netns-only obsolete. The slight wrinkle here is that you can't re-enter the userns you're already in. So, we have to test if the ns returned by NS_GET_USERNS is the one we already inhabit. According to namespaces(7) we can do that by using fstat/stat and checking the device and inode of the fd from NS_GET_USERNS versus that of /proc/self/ns/user. So, I think we should straight out deprecate --userns and --netns-only for the PID/--netns case. NS_GET_USERNS is basically an all around better solution. For COMMAND mode, NS_GET_USERNS can't help us, because we need to locate the userns before we can create the netns. We still have the three options of where to create the new netns: * In a new userns (default) * In our current userns (--netns-only) * In a different existing userns (--userns) With that in mind, opinions on the specific behaviours we should aim for below.
It would be good to have a way to "cleanly" exclude this new behaviour, but, once we add the NS_GET_USERNS trick, --netns-only doesn't exactly get us back to the previous behaviour. What about --userns-from-pid or something like that? That name isn't great though.
I agree that this would be one of the possible solutions. It would enable the use either with PID or with the --netns option. Maybe --userns-from-netns would be better? Somehow it would be cool to include the relationship between userns and netns more concretely like --join-owning-userns-from-netns, but on the other hand it is also a bit too long.
However, I am not sure, if it is really necessary to have a separate CLI option. Maybe it would also be a fine new default behavior just for the case when a PID is specified, but no network or user namespace is explicitly given. If anyone really needs the old behavior, it is still possible to specify the user namespace explicitly and, therefore, deactivate the new behavior. It seems that podman uses the --netns option, so it should be fully unaffected by this proposed change of default behavior.
I am fine with both solutions. I thought a bit more about the current and changed behavior by iterating trough the possible combinations of options with my code changes in mind. I hope this is not too much, but it also uncovered a few already existing strange edge cases.
Here's what I think we should do for each case (many of these match Lisa's suggestions). This aims to keep old kernel compatibility as best we can.
CLI options -> behavior ----------------------------------------------
PID -> new behavior (netns from PID, userns from netns from PID with fallback to userns from PID)
netns from pid, userns from NS_GET_USERNS. If NS_GET_USERNS fails, userns from PID.
--netns-only PID -> new behavior (netns from PID, userns from netns from PID with fallback to userns from PID) ***2 It looks like this is currently already a strange behavior, as it would get the netns and userns from PID.
netns from pid. Check NET_GET_USERNS, if it succeeds, but isn't the same as our current namespace, exit with error. If it fails, userns from PID.
--userns X PID -> existing behavior (netns from PID, userns from option)
netns from pid. Check NET_GET_USERNS, if it succeeds, but isn't the same as given userns, exit with error. If it fails userns from option.
--userns X --netns-only PID -> new behavior (netns from PID, userns from netns from PID with fallback to userns from PID - strange) ***1 It looks like this is currently already a strange behavior, as it would also get the userns from PID.
Fail with an error. This already makes no sense, because we're giving contradictory instructions on what userns to use.
--netns-only --userns X PID -> existing behavior (netns from PID, userns from option - strange) ***1
Same case as previous.
--netns X PID -> existing behavior (invalid) (skipping further combination with --netns and PID)
Fail with an error (as we already do).
--netns X -> existing behavior (netns from option, no userns)
netns from option, userns from NS_GET_USERNS. If NS_GET_USERNS fails, exit with error.
--netns X --netns-only -> existing behavior (netns from option, no userns)
netns from option. Check NS_GET_USERNS, if it succeeds but isn't the same as current namespace, exit with error. If it fails, fall back to keeping current userns and hope for the best (i.e. existing behaviour).
--netns X --userns Y -> existing behavior (netns from option, userns from option)
netns from option. Check NS_GET_USERNS, if it succeeds but isn't the same as given userns, exit with error. If it fails, fall back to using given userns and hope for the best (existing behaviour).
--netns X --userns Y --netns-only -> existing behavior (netns from option, no userns - a bit strange) ***1
Fail with an error.
--netns X --netns-only --userns Y -> existing behavior (netns from option, userns from option - strange) ***1
Same case as previous.
COMMAND -> existing behavior (new netns, new userns)
Existing behaviour.
--netns-only COMMAND -> existing behavior (new netns, no userns)
Existing behaviour.
--userns X COMMAND -> existing behavior (new netns, userns from option)
Existing behaviour.
--userns X --netns-only COMMAND -> existing behavior (new netns, no userns - a bit strange) ***1
Fail with an error.
--netns-only --userns X COMMAND -> existing behavior (new netns, userns from option - strange) ***1
Fail with an error.
--netns X COMMAND -> existing behavior (invalid) (skipping further combination with --netns and COMMAND)
Fail with an error (which is existing behaviour).
Although it is not directly related to the change I am proposing, it might make sense to clean up the CLI option behavior a bit. I would argue to forbid --userns in combination with --netns-only completely (everything marked with ***1).
As noted above, I agree. This already makes no sense.
Furthermore, --netns-only PID seems to be currently broken (marked with ***2). I think the netns_only variable (or use_userns how it is called inside isolate.c) should most likely get higher priority than the userns variable itself. This should fix the behavior to only use the netns from PID and no userns.
Oh, interesting. As above, I think we should deprecate this case anyway (with NS_GET_USERNS + checking if we're already in the right namespace, it's not necessary). If it happens to already be broken, that gives us an excuse to just remove support without going through the deprecation process.
Now, 4.9 feels "old" enough, but pasta used to run on a 3.13 kernel a while ago, then a few things were (inadvertently) broken. But it "almost" does. Couldn't we just add a fallback for the case where NS_GET_USERNS fails? You're already handling the error. You could just print a warning and continue instead of calling die_perror()...
For the plain 'PID' case this makes sense. For other cases it's murkier - we may have no reasonable fallback, or the "fallback" might contradict the behaviour we'd have in the case that NS_GET_USERNS succeeds, which would be weird. I've opined on each case separately above.
Yes, it makes sense to implement a fallback when changing the default behavior. If it will become a separate option, it seems counter-intuitive to have an automatic fallback. I just thought it might be best to first discuss the wanted behavior before starting to implement more complex changes.
Yes, that makes sense. Are you comfortable with implementing the behaviour I've described above? I could tackle this, but I'd love for someone else to do it instead. If you are happy to tackle it, two small suggestions: - start with a preliminary patch to make combining --netns-only and --userns an error. That never made sense and making it explicit is a good idea regardless of what else we do. - Another preliminary patch can add a "namespaces_equal" helper, since that will ne needed in a number of places. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson