Re: Issues when using pasta with bubblewrap

[Lisa Gnedt <lisa+passt-user@gnedt.at>]

Hi,

On 2025-07-17 14:58, Stefano Brivio wrote:
> Apologies for the delay.

No worries.

> Ah, I see. Well, in that case, I guess we could simply skip the
> NS_GET_USERNS ioctl() if --userns is given.

Yes, this is exactly what I am suggesting with my table below to change
the current default behavior only when a PID is supplied.

> Would --userns-from-netns imply that the PID given on the command line
> always refers to the network namespace, and the user namespace comes
> from it? If that's the case, the name looks fitting (but it needs a bit
> of explanation in the man page and usage message).

Yes, but it would also be usable with the --netns option. That's also the
main difference when compared to the other suggestion of changing the default
behavior when only a PID is supplied.

> Right, Podman shouldn't be affected at all. I wonder about rootlesskit
> (used by moby / Docker) though:
> 
>   https://github.com/rootless-containers/rootlesskit/blob/3c8213d359b54284f4f0aa373ef9adb61d913e0e/pkg/network/pasta/pasta.go#L178
> 
> from what I understand, --netns is passed to pasta only if the user
> gives an explicit --detach-netns. Now, even with the change you
> propose, things should always work, but I guess we should test it at
> least in the common use case (Docker starting a container).

Good point.

>> --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.
> 
> I'm not sure about this part: the intended behaviour is to only care
> about a target network namespace, because who starts pasta already
> joined / detached the intended user namespace. You mention it's broken
> but I'm not sure why.
> 
> I don't think the behaviour should change here.

Maybe I was not very clear about this case. I think the current behavior
of the code is broken and does not do what you described (why see below).
When we leave this broken code like it is now and apply the code changes
I have in mind, this would result in the changed behavior described in the
table that is still broken.
Therefore, I think the best outcome would be to also fix the issue,
which should then result in the behavior you describe, skipping user
namespace handling all together and assuming we are already in the correct
user namespace.

>> 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.
> 
> I'm not quite sure what the current problem is.

Maybe let's go through the conf() function when the command line --netns-only PID
is given and see what happens to the userns and netns_only variables.

1. Initialization
   Set userns = ""
   Set netns_only = 0
2. Parsing of --netns-only argument in getopt_long loop
   Set userns = NULL
   Set netns_only = 1
3. Parsing of remaining opts in conf_opt_ns()
   Since PID is a number and userns is false (ignoring the fact that netns_only is 1):
     Set userns = "/proc/{PID}/ns/user"
4. Calling isolate_user() with use_userns = !netns_only and userns = userns
   Since userns is set, join the given user namespace
   (ignoring the face that use_userns is false since it would be only checked if
    userns is not set)

I think the problem needs to be fixed either in 3. or 4. respecting the netns_only/
use_userns options, so that no user namespace would be joined.
When this is fixed, then the behavior would stay the same even with my
intended changes of the default behavior I described. This was a bit misleading
in my posted table since it assumed that it will not be fixed.

Best regards,
Lisa