From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=reject dis=none) header.from=gnedt.at Authentication-Results: passt.top; dkim=pass header.d=gnedt.at header.i=@gnedt.at header.a=ed25519-sha256 header.s=ed25519-1 header.b=eDUbT1jp; dkim=pass (2048-bit key; secure) header.d=gnedt.at header.i=@gnedt.at header.a=rsa-sha256 header.s=rsa-1 header.b=bPDNUIZP; dkim-atps=neutral Received: from mail.davizone.at (mail.davizone.at [IPv6:2a01:4f8:190:7398::1]) by passt.top (Postfix) with ESMTPS id CAAC95A0280 for ; Sun, 20 Jul 2025 01:04:02 +0200 (CEST) Received: by mail.davizone.at (Postfix) with ESMTPSA id 28E311200E7; (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) Sun, 20 Jul 2025 01:04:02 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=gnedt.at; s=ed25519-1; t=1752966242; 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=3LdH3B41jyofN/U2s2JkGcWPwSEeZx9rdB9O7RJWXYY=; b=eDUbT1jpDh0kwrBn44Ipho5c7FjfvnCqEMLrnXlIdl/uJB98SoerIaWflhvCoj0LDW+OHr yn3VdYiB/MxltAAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gnedt.at; s=rsa-1; t=1752966242; 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=3LdH3B41jyofN/U2s2JkGcWPwSEeZx9rdB9O7RJWXYY=; b=bPDNUIZPvSwPSUfMNzBS3dRErtuMMWpmOo7QUC7D4pzqLf2Evw5LxBiZYglpdOdHZA38+g xwE/1zsYOpWj0ElJmMBH8SFzdUEdrcrTBk4dnoGjOtonqzyvfgQDocsu2NF5g0T892Ml2r 7AuZQnwqIY5xYZTUpwj73I4cRYlzhp3bsNQEkB3IxncByX8kvIdHLxlA6R3OYcr/th4KtO HTzRQaPEfFYwytqJhPFtjJheoV8nuSXmA7TlxXxCsw2Atw0W/z1VyTSvNvy5VA6WLzvLX8 Gd23QOo02g1bJlr9BwNo3XzrcYeNVqrknfoDmYN/8xgkkIjnGUhrfsidX+tmjQ== X-Davizone-Smtp-Source: b2vcehHDlSCQs0AMzvnSQXoy1pkoIBgdc/T/zjvIpjzeOW1dnWsiRk1xYXHYq2FZ8RYrMDXr sHOwpm+i71pmSAHluawnV/HR0cSauFu22wd8aKVM/vIARtsqZ1Wq3Vc5gF5a5sIKV36KMHFY Upv3onldOCvFdCWhUY2jIAQ2zfqva18EM9JztXhTd7AZ5/5o5RcrnOrk9lMVJu4YlZmCj98D Qd4iZqXp+EwOn/SDDW3sUhNVIjtaVJZAtof2ZYRNObu6HBNMhqq04SnGAQ== Message-ID: <06ea0f8a-b85a-482c-8ced-d872070c4ace@gnedt.at> MIME-Version: 1.0 Subject: Re: Issues when using pasta with bubblewrap To: Stefano Brivio References: <671252c8-88f6-45b7-b719-b82786e84bb7@gnedt.at> <175188240057.3062894.4319502484182397394@maja> <20250707181903.6ec6ce82@elisabeth> <20250717145857.081ed2f5@elisabeth> Content-Language: en-US, de-AT From: Lisa Gnedt In-Reply-To: <20250717145857.081ed2f5@elisabeth> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-MailFrom: lisa+passt-user@gnedt.at X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: STIASGTSZWOI4HC6J7M6RPW6M7EOSE5Z X-Message-ID-Hash: STIASGTSZWOI4HC6J7M6RPW6M7EOSE5Z X-Mailman-Approved-At: Mon, 21 Jul 2025 13:01:00 +0200 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: Date: Sat, 19 Jul 2025 23:04:03 X-Original-Date: Sun, 20 Jul 2025 01:04:01 +0200 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