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=CHeI/7dG; dkim=pass (2048-bit key; secure) header.d=gnedt.at header.i=@gnedt.at header.a=rsa-sha256 header.s=rsa-1 header.b=odOsZBFJ; dkim-atps=neutral Received: from mail.davizone.at (mail.davizone.at [144.76.3.172]) by passt.top (Postfix) with ESMTPS id C2DF15A0282 for ; Wed, 09 Jul 2025 01:54:37 +0200 (CEST) Received: by mail.davizone.at (Postfix) with ESMTPSA id 4A5E21200E7; (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) Wed, 9 Jul 2025 01:54:37 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=gnedt.at; s=ed25519-1; t=1752018877; 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=01p1gVMQKITbyu/xmSurAwuvTzE5CQ+XGLDIGZDP794=; b=CHeI/7dGIXn2bkoCJz1CMlTiJAwgV6rK96UZI3ctBcdL6tdfO7N9FHQ9ImY0C926HZsY/b S0+EZSeWhQuE5mDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gnedt.at; s=rsa-1; t=1752018877; 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=01p1gVMQKITbyu/xmSurAwuvTzE5CQ+XGLDIGZDP794=; b=odOsZBFJL2/NQD8SFa63LswQBKghbQR4sNMOqEeObV/yozUlq3ihFGbPSd+nfSsC2L+hT1 /vUwwylMuBp9tJMANXNqK11TwiBa9OZCZ3CpuoI9BG5sANo+p7+ngQ4FOoGYSmU/SSX0tS C5i+RN8AmyJIKWY2E0fLXQaRR80126ueJ6ARbirJUfk0ZkALkeMAK0X77RkLQm4utUqq/q OEsuZ9aYoXD8nNJCc8qSYbfjIx/HVBkn4olj7ZOewQsHcJbrKNbWhRq8SOm75GmTnr2b9P Z/g+DvQ7ZDGOKHmrzTZ/rc5YHkDocVvhqaypTi2nc64MZEeXmPafcaP6WGXHzQ== X-Davizone-Smtp-Source: q2pUE0RCFlpzjfL2EfgFyWJxNriHlYL7XsJooPqj9NZoAnEbjfawWxwTimB5jGqEcO/Zx+7o 45ZphQlGs8RXGbYUlR1uvv3QAK+1PmXNopXbrXZURCC7k5clHQLNiah9TMbehvq5aGI7KTte wqueLKzej7Moglfy5Ekpy7yrfGf/x1jZbzpl6P+CiG3mXCHxMqu7X5MAeJpKEUvcYf7hg0fn dB0AYj3esgRLb6ALxx5HWhWNf8w0OeKCWOUqwzO0yEGIAAOnGMuJtqQ1zA== Message-ID: Date: Wed, 9 Jul 2025 01:54:36 +0200 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> Content-Language: en-US, de-AT From: Lisa Gnedt In-Reply-To: <20250707181903.6ec6ce82@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: LLPVDZW7E2NSQEOUVHOODEDGHIJAWXSX X-Message-ID-Hash: LLPVDZW7E2NSQEOUVHOODEDGHIJAWXSX X-Mailman-Approved-At: Wed, 09 Jul 2025 09:49:47 +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: 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. > 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. 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. 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. --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 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). 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. > 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. Best regards, Lisa