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=JoqbI8kY; 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 387C35A0280 for ; Mon, 07 Jul 2025 18:19:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1751905149; 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=M6wuWgiOCGsxWbAKRQfg70oAs2Nn13XoyXWvQXXAkjE=; b=JoqbI8kY4xsuH2oEUEMrMkkPmvRr7+TwG8KhLuPXzAG0KooOmgbO1A3OtMbiinGwDdfkLh K8hdJGCvTswLsPDbOvftePkquFBBwgzn/JJS83WjeEF0txtXjiUB3wlo6TuOewWHwyEMcj gKJZWSeTedeaRcQ2FQQSvLyjw27bd40= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-613-doOft7KUP0WkdkbZeGIt9g-1; Mon, 07 Jul 2025 12:19:07 -0400 X-MC-Unique: doOft7KUP0WkdkbZeGIt9g-1 X-Mimecast-MFC-AGG-ID: doOft7KUP0WkdkbZeGIt9g_1751905146 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4538a2f4212so17523035e9.2 for ; Mon, 07 Jul 2025 09:19:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751905146; x=1752509946; 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=M6wuWgiOCGsxWbAKRQfg70oAs2Nn13XoyXWvQXXAkjE=; b=tZ4zPnhE4JAFprxqbav37m5horBPAH6rW82FtsbJWMaNU0WS2yqFruiJ25IKxmPNCx /kvfznK5P6nRLtKViDUHBWVqAwVukTUX8fgHnCTyVp7cqcWtpsP6yOQb6xUTzLH/mGMJ CRCeyUowsqA4WO0AFDgEs499t7MUZJ+yM785Q5gxDSWzHBc8c1652ewCPIL/NRXJGgT1 6Dt7lBmEmbMbhCjB8MYmHxQVqODEcmhQVDF/staL6pAIQROUXVUlAvnD7j6sedb11E6H zZnRXm9Ub043qC6bfv4jkAXJxyxTfPBQXt96vzWTa8Vo52lJ2Jslln+NCn4MMaFfHuXR Nj3w== X-Gm-Message-State: AOJu0YwfmucUAS71JOmg04DukZI2cEewYjiuojpoVjxrXi7JtRUooMwL O2+xEmLBaZ4AXCDZIypMqGoj6o0hQQk7HA+Lt+lE2+da+ZCGIiMA7wbJQ4l9XXPfhrBA36B4khA 9/DljQHqW7gboyiPXcXMP1aHv+soOdkiRyXR1OgE6Sitt0MWmi1uNsIM= X-Gm-Gg: ASbGncuwklB9PMWLsu0fJiYkw7PWHHykt7575Ku2MtcLQaRvu/pAs0oyM2893YmSjB7 7ysEdGADf1nRm4t4aJrp1LaagdW1qCyl4b1L+lI0fLf6+LXM7qCiWyX2Zezt9lzNmylrmmxUKDA KLdBDXU5ylZJgHHqbBHzDPlomQJmnKFTF+oAnzfbuVHQTT184K1Yb/pSQ0rj18yOW84rpcLUDFs Drxqcg3WZ5uze2x93eL3omjK5mLTUbplOwT9xoEJpKRqj5Hw4RdiiuJ3NnhwY5uyB0J7AYbHjAZ UIC4L5JKPBEkQIAEBuc8zX2h57zuORBaxX3ZBG9I0YNptVFU4lg= X-Received: by 2002:a05:6000:480b:b0:3a5:8600:7cff with SMTP id ffacd0b85a97d-3b49aa42b8amr7297969f8f.1.1751905145879; Mon, 07 Jul 2025 09:19:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGnpt1rPCQrhSFF8YmxPHb739TU8in2XXk+J+tM5JYnSmyKc7+dhNyOOgJjXP7Pa0fqGOE3tQ== X-Received: by 2002:a05:6000:480b:b0:3a5:8600:7cff with SMTP id ffacd0b85a97d-3b49aa42b8amr7297951f8f.1.1751905145388; Mon, 07 Jul 2025 09:19:05 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b4708d0ed9sm10804125f8f.38.2025.07.07.09.19.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jul 2025 09:19:04 -0700 (PDT) Date: Mon, 7 Jul 2025 18:19:03 +0200 From: Stefano Brivio To: Lisa Gnedt Subject: Re: Issues when using pasta with bubblewrap Message-ID: <20250707181903.6ec6ce82@elisabeth> In-Reply-To: <175188240057.3062894.4319502484182397394@maja> References: <671252c8-88f6-45b7-b719-b82786e84bb7@gnedt.at> <175188240057.3062894.4319502484182397394@maja> 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: m8EnFiI1ACkKgt_J__39068UG-wNa-ms3t3KchBaH4U_1751905146 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: ETRA73QIFLUNJAY722QEMZLDPQNEHYEH X-Message-ID-Hash: ETRA73QIFLUNJAY722QEMZLDPQNEHYEH 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: [Cc'ing Paul as Podman maintainer, thread at: https://archives.passt.top/passt-user/671252c8-88f6-45b7-b719-b82786e84bb7@gnedt.at/] On Sun, 6 Jul 2025 19:08:46 +0200 Lisa Gnedt via user wrote: > Hi, > > On 2025-07-06 17:15, Lisa Gnedt wrote: > > It might be easier to get it correct when directly controlling all > > syscalls involved and not have to mix and match multiple tools. > > Since Linux 4.9 it seems to be possible to get the owning user namespace > > of a network namespace with the ioctl NS_GET_USERNS [3]. > > I just wrote a hacky patch as proof-of-concept of this idea. > It is working for me fine in both testcases. > However, in its current form it breaks the --userns parameter. But it should not be too hard to address this issue. > > I am not sure, what kernel version compatibility you are targeting, since the ioctl is only available since Linux 4.9. > Would it be an option for you to make it the default behavior when a PID is specified? > >From my perspective this should be the expected behavior and should not break any previously working use case. I finally had a second look, a bit quicker than I wanted but I think I grasped the issue. For context, "this" is: always join the user namespace owning a network namespace. It looks reasonable (and desirable) to me, but I'm not sure how / why it breaks the --userns parameter. We should probably never do this when --netns-only is given (that's Podman's case, for example). 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. 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()... > diff --git a/conf.c b/conf.c > index 36845e2..cd67e7a 100644 > --- a/conf.c > +++ b/conf.c > @@ -642,7 +642,7 @@ static void conf_pasta_ns(int *netns_only, char *userns, char *netns, > > if (!*userns) { > if (snprintf_check(userns, PATH_MAX, > - "/proc/%ld/ns/user", pidval)) > + "/proc/%ld/ns/net", pidval)) > die_perror("Can't build userns path"); > } > } > diff --git a/isolation.c b/isolation.c > index bbcd23b..cbfe0f0 100644 > --- a/isolation.c > +++ b/isolation.c > @@ -81,6 +81,7 @@ > #include > #include > #include > +#include > #include > > #include "util.h" > @@ -254,6 +255,14 @@ void isolate_user(uid_t uid, gid_t gid, bool use_userns, const char *userns, > if (ufd < 0) > die_perror("Couldn't open user namespace %s", userns); > > + int real_ufd; > + real_ufd = ioctl(ufd, NS_GET_USERNS); > + if (real_ufd < 0) > + die_perror("Couldn't get user namespace from network namespace %s", userns); > + > + close(ufd); > + ufd = real_ufd; > + > if (setns(ufd, CLONE_NEWUSER) != 0) > die_perror("Couldn't enter user namespace %s", userns); > -- Stefano