From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=KqLo3Jy+; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id B535F5A0280 for ; Thu, 17 Jul 2025 14:59:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752757147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=og68mJJKu+sHAMHI6g+eF/JWTiq3NEgcNy44I6K/hsk=; b=KqLo3Jy+twHnHvrNjiq3rpYKNXz3npxMrZ7k/HIRGziUKeFKQ/zAYnvvUgp++uxUo9rtKN i1vAfAFvmmjiq1SkncUXOedGLO09E6OTeiknaJVA8Xt2NlvrHy7S/mP00mDCrTfzlRSBPi 6Vp9JSo1EaB8HXwbrIKmp8VGCjrV01Y= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-473-irMP2aMVNFiYKdLIYtM1XA-1; Thu, 17 Jul 2025 08:59:06 -0400 X-MC-Unique: irMP2aMVNFiYKdLIYtM1XA-1 X-Mimecast-MFC-AGG-ID: irMP2aMVNFiYKdLIYtM1XA_1752757145 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-455e918d690so12510765e9.1 for ; Thu, 17 Jul 2025 05:59:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752757145; x=1753361945; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=og68mJJKu+sHAMHI6g+eF/JWTiq3NEgcNy44I6K/hsk=; b=u3VnmsLw5c4ws3mgW+JBM7Z8wbukrl0N2+0PFOMFp3Qz7in2l09QMUVktgM13teQ5S jqFEyGVJlSMoMFGef9czkCFGwErFb06CdyOHdsITicL1phcMIQDy1+yLFAFr0XmbDGKP tCEmU/5RBuGj/Y22i+Z2BbNYpHd8LJ/zLykJvHA/T3moJVsfPpp/+Hml5z1QnITIoIJv tDOnOrkALXcaQg1OjQEa+DiEuU9skpmQpOCROtkr6c0leQyB/LvnEIP75kSU/SNW5h2W yKFBYPPMYsNQZS1cB1YA4BsqneRISQ5JmW2pi11WfBn36ZIX7jlhagxrLNbNCO2elkCQ 5D+w== X-Gm-Message-State: AOJu0YzDwljmrEZzvpfoVZ4wgnO5zl8FNuw9HQ/geohSUUPQbF6NLhxj oMGbw86644VNLtdWwHQQLeXbWlsGNB3hpAChFg2LUBspD9D/7hoGa41VeD6HDK4Rtzxa9L38JK/ G9+V2wJuLTlQZI/3LWhtjKXf8W/CedXa3pGVfWfKbZT0gbK/Q1qQj49k= X-Gm-Gg: ASbGncvTXAWbZz4i/MXBTqJEigv5tqUeYS1WwBV5nWaDOnRApPl4YfczlgEkGQYiuxW D8hIg8bgITnqenVsoymFp3YF4xziGYcLbn1vGfuNKy1gxvJG9lDg1oQQBe7Zd7B7HE4Q2wAKmk4 j4QZj5epjIYB0D0MtOIIUXnNg1FOIynbkWXG6Lz36PbV8FkMIAg1aCSb9LDKYDZVing3eZHu9xM Lta2kPBTe3B0BGUeP7I5U07fTwMxKuIN1E662/PNl71DM4aaB6FOmyXb/noYqZdrT+4O2xBjd57 GdfJesotfvD9Uc74BQ682cd27JYH9ou79ElQ4a3Te4/901UogMBY0anB7gaJDvqx2bZy X-Received: by 2002:a05:6000:645:b0:3a5:8991:64b7 with SMTP id ffacd0b85a97d-3b613a3ef64mr2516778f8f.26.1752757144870; Thu, 17 Jul 2025 05:59:04 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEnyFKJyo4LRzHnVtQAShyZSxpggyrDk7InhTqgtmT82Qdub7/5IX0upf3iOWwXmvy1yC2Dug== X-Received: by 2002:a05:6000:645:b0:3a5:8991:64b7 with SMTP id ffacd0b85a97d-3b613a3ef64mr2516747f8f.26.1752757144272; Thu, 17 Jul 2025 05:59:04 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45634f8dba0sm21628415e9.27.2025.07.17.05.59.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Jul 2025 05:59:03 -0700 (PDT) Date: Thu, 17 Jul 2025 14:58:57 +0200 From: Stefano Brivio To: Lisa Gnedt Subject: Re: Issues when using pasta with bubblewrap Message-ID: <20250717145857.081ed2f5@elisabeth> In-Reply-To: References: <671252c8-88f6-45b7-b719-b82786e84bb7@gnedt.at> <175188240057.3062894.4319502484182397394@maja> <20250707181903.6ec6ce82@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EdNHbLppSCh_NMFj2nNkzca4-R0zTLxN-NKg-M_o1k8_1752757145 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: I3LUMZGWRPIBVCIVZKTX7FC6SLTBEKQ6 X-Message-ID-Hash: I3LUMZGWRPIBVCIVZKTX7FC6SLTBEKQ6 X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-user@passt.top, Paul Holzinger X-Mailman-Version: 3.3.8 Precedence: list List-Id: "For passt users: support, questions and answers" Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Apologies for the delay. On Wed, 9 Jul 2025 01:54:36 +0200 Lisa Gnedt wrote: > Hi Stefano, > > 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. Ah, I see. Well, in that case, I guess we could simply skip the NS_GET_USERNS ioctl() if --userns is given. > > 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. > > > 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. 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). > 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. 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). > 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. > > CLI options -> behavior > ---------------------------------------------- > > PID -> new behavior (netns from PID, userns from netns from PID with fallback to 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. 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. > --userns X PID -> existing behavior (netns from PID, 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. > --netns-only --userns X PID -> existing behavior (netns from PID, userns from option - strange) ***1 > --netns X PID -> existing behavior (invalid) > (skipping further combination with --netns and PID) > > COMMAND -> existing behavior (new netns, new userns) > --netns-only COMMAND -> existing behavior (new netns, no userns) > --userns X COMMAND -> existing behavior (new netns, userns from option) > --userns X --netns-only COMMAND -> existing behavior (new netns, no userns - a bit strange) ***1 > --netns-only --userns X COMMAND -> existing behavior (new netns, userns from option - strange) ***1 > --netns X COMMAND -> existing behavior (invalid) > (skipping further combination with --netns and COMMAND) > > --netns X -> existing behavior (netns from option, no userns) > --netns X --netns-only -> existing behavior (netns from option, no userns) > --netns X --userns Y -> existing behavior (netns from option, userns from option) > --netns X --userns Y --netns-only -> existing behavior (netns from option, no userns - a bit strange) ***1 > --netns X --netns-only --userns Y -> existing behavior (netns from option, userns from option - strange) ***1 Thanks for the table, it's really helpful, and everything else makes sense to me. > 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). Right, that's probably a good idea. By the way, I'd suggest checking with David Gibson as well, as he's going to get back online soon (at some point next week) and he took care of the most recent rework in this area. I'll take care of asking him to have a look at this thread when he's back. > 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. > > 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()... > > 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. -- Stefano