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=jV4wug4t; 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 7EECF5A0265 for ; Wed, 09 Sep 2026 23:02:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788987756; 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=aIGL6KE//qEi8Pd3F4z97W+0MOvGHe8yt3BAMB5qaZc=; b=jV4wug4tskj47hyvszuhwcoMgWaGa7Bm2s18jCaITxlvGhAMlGfKsoM8PRxfC1p6zVb/4M Kww40o8ShPWI3onGqUc6qDADvdASUm8/6fosN/2/wNOvDyvNhPHJ3vvKopDbDbUm3cKM5c pw9IbhMgFW9PL3myF/A4RffaZg1HC5A= 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-563-4oYqFQYBNwqicaBSXajHpQ-1; Wed, 09 Sep 2026 17:02:34 -0400 X-MC-Unique: 4oYqFQYBNwqicaBSXajHpQ-1 X-Mimecast-MFC-AGG-ID: 4oYqFQYBNwqicaBSXajHpQ_1788987754 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-49cdc4080ddso1235325e9.1 for ; Wed, 09 Sep 2026 14:02:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788987753; x=1789592553; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=aIGL6KE//qEi8Pd3F4z97W+0MOvGHe8yt3BAMB5qaZc=; b=MrEZdLu6knsOT3uwjcGC0thGsZlV0Ea2tLGyfUmn9cBTK8w4rbsFbViDOO+pc3adC+ AA0WaWkfE9ATYbn1gKWXpHMhfNjElYoo/yHiYsWaN/NODDokpvdqpC3f8cbFsTGwtOIG MJQKI6lbmodfM+uJxAV66pYZ/kvQBtsOuaOpwAausPhnaFbbLcIGFvi0FxFPd3vnKjTJ fCMQtKEW50QAVQERl1HN9wKAFhSSLhcHpeiqp9neIU7v0ULvo4x4qbrE05Dxg/2ufTGb KjvR/J/NOh7sbmkEnkYmW56mo2sbZ9+1Tez6vPOnpdxRXTqWAMWoL2+rsI9YmHTr+P/d naNw== X-Forwarded-Encrypted: i=1; AKwUvBwIijJV8EfkQEk3c7h38GM5mJoxTsBSf3VSNA2Jmw6va2MwVhAFlhcaOSuBO+m0MpzlLfCYGRJ2rqc=@passt.top X-Gm-Message-State: AFuF++lVUpDg4hkdsHflWjTztyW+bIOEPRiGc92voqf2LYmwdKhj1UuE RliocyCgrT5+1bI/w1lnj/TILVANRFS0O+hnv0GafM+z6//8cwoahop3FgnptTO4kq+ZhnxRqU1 l4BeIl4NtU1VDWr3KBChLQy3Omnq5ouXb0BguVAUCPyDms0JC28OY/OfxBzvDOA== X-Gm-Gg: AYBFou3XfmvrD2bdvQ20HBc7MCK39XCmbOdr0VKNHhEOMXnqJOv45wxE5R3C6YPyqGO H9zvPvh68hcGY+9C6eOuLIFqcrOogTe2v/TwdFpWfrgUkuToVAPTbRaJh4chWg0QIettFUSVZah DG9iabOmYNPf17BC/n6O+QMkAQEmHPktqYOYshCyruMLa+RrxrI0kH7UFMFznrxHDJevMC2HrUb Txv3ph6Xi4y93FIMejGeLDwKJNH+69K4F1h8wkP+uNpr4qLWZ45cHHJAjWnuWHreT0bhKtDNAOX vPq29rgO5oFJBf7TrBpE4ypE/UDEbJQHnhTzI0t2SKKJaRu6bQduuvWX4Ss7u3TMPVK0LXiiYuA 1J8s86ceVMkE= X-Received: by 2002:a05:600c:4fcb:b0:49c:f13e:e4c with SMTP id 5b1f17b1804b1-49d26db4274mr11486845e9.9.1788987753474; Wed, 09 Sep 2026 14:02:33 -0700 (PDT) X-Received: by 2002:a05:600c:4fcb:b0:49c:f13e:e4c with SMTP id 5b1f17b1804b1-49d26db4274mr11486615e9.9.1788987752959; Wed, 09 Sep 2026 14:02:32 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49d26bc08edsm10948645e9.3.2026.09.09.14.02.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 14:02:29 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] pasta: Add --no-pidns to keep spawned command in caller's PID namespace Message-ID: <20260909230228.729e8f8b@elisabeth> In-Reply-To: References: <20260906131758.121019-1-christian@korneck.de> <20260908114506.49f6ddd4@elisabeth> <20260908173233.429652e0@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Wed, 09 Sep 2026 23:02:29 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: YnoBWOtG1bkbeF2u1RoGd8vC3SX_0U79o2WYlApUaqU_1788987754 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: RZ4J2CXJSTCKBCG5M26JWMWGQXFAM357 X-Message-ID-Hash: RZ4J2CXJSTCKBCG5M26JWMWGQXFAM357 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: Christian Korneck , passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 9 Sep 2026 16:00:25 +1000 David Gibson wrote: > On Tue, Sep 08, 2026 at 05:32:34PM +0200, Stefano Brivio wrote: > > On Tue, 8 Sep 2026 21:09:36 +1000 > > David Gibson wrote: > > > > > On Tue, Sep 08, 2026 at 11:45:07AM +0200, Stefano Brivio wrote: > > > > On Tue, 8 Sep 2026 16:03:07 +1000 > > > > David Gibson wrote: > > > > > > > > > On Sun, Sep 06, 2026 at 03:17:58PM +0200, Christian Korneck wrote: > > > > > > This is to allow running pasta inside a container without unmasking > > > > > > /proc for the whole container (Docker's --security-opt > > > > > > systempaths=unconfined, Podman's --security-opt unmask=ALL), which is > > > > > > undesirable as it exposes /proc/sysrq-trigger and other masked paths. > > > > > > > > > > > > In spawn mode, pasta clones the command with CLONE_NEWPID and mounts a > > > > > > new procfs instance on /proc, so that it matches the new PID namespace. > > > > > > > > > > > > Mounting procfs in a new user namespace requires a fully visible, > > > > > > unobstructed procfs. Container runtimes deliberately obstruct /proc > > > > > > (Docker, for example, masks /proc/kcore and friends and mounts > > > > > > /proc/sys read-only), so the mount is refused: > > > > > > > > > > > > Couldn't mount /proc: Operation not permitted > > > > > > > > > > > > We only warn and continue, leaving the command in a new PID namespace > > > > > > while the visible /proc still numbers processes in the outer one. > > > > > > Anything resolving its own PID through /proc then fails, for example > > > > > > bubblewrap: > > > > > > > > > > > > bwrap: open /proc/22/ns/ns failed: No such file or directory > > > > > > > > > > > > Add a --no-pidns option: skip CLONE_NEWPID for the spawned command and > > > > > > don't mount /proc, which is then not needed. User, network, mount, UTS > > > > > > and IPC namespaces, --config-net and port forwarding are unaffected. > > > > > > The option is rejected together with PID or --netns, as it only makes > > > > > > sense when we spawn the command ourselves. > > > > > > > > > > > > Add a test checking that, by default, the command runs in a new PID > > > > > > namespace, and that --no-pidns keeps it in the caller's one. > > > > > > > > > > I can see that this would be useful. On the other hand, I could say > > > > > that for just about any combinatiom of unshare(1) options, and I don't > > > > > think we want to reimplement all of unshare(1) in pasta. > > > > > > > > Certainly we don't, but we don't get requests like these frequently > > > > (except for the one to drop namespacing altogether, which is another > > > > story), so I think it's acceptable. > > > > > > Fair point. > > > > > > > The patch looks also pretty good and complete, so really low effort from > > > > my side. > > > > > > > > > Note that it > > > > > is always possible to create a namespace using unshare(1) with > > > > > arbitrary options and then connect it with pasta, rather than having > > > > > pasta create its own. > > > > > > > > > > That said, I've never seen the point of creating a pidns by default in > > > > > pasta. We're not isolating the filesystem, so I don't see that > > > > > there's much to gain by isolating pids. I'd be happy enough to see > > > > > CLONE_NEWPID removed unconditionally. > > > > > > > > The points are described in the message for 0515adceaa8f > > > > ("passt, pasta: Namespace-based sandboxing, defer seccomp policy > > > > application"): > > > > > > Sorry, to be clear, I absolutely see the point of CLONE_NEWPID for > > > passt/pasta itself. It's specifically for the spawned shell/process > > > that I don't see the benefit. > > > > Ah, yeah, in that case it's just about cleaning up. > > > > > > - no need to track child processes: when PID 1 exits, they all > > > > terminate, instead of that crazy / buggy hack I implemented before > > > > this change > > > > > > I guess. But is cleaning up the spawned process really pasta's job? > > > > Perhaps not (see below), but it's extremely convenient, especially if > > one runs nested pasta or a bunch of commands in subshells as a > > one-liner reproducer, which is the main usage of it for myself and > > quite a few people judging from bug reports. > > Hm, ok. Do you often encounter programs that don't neatly clean > themselves up? Just nstool nowadays. But my "issue" was rather spawning subshells in my tests or daemonising stuff (say, tcpdump, iperf3, nested pasta) for convenience, not really buggy tools. > > Before 0515adceaa8f, I spent some substantial effort to make sure that > > the previous hack would clean up as much as possible, because I used to > > constantly end up with a pile of 'ping' processes, HTTP clients / > > servers, iperf3 instances, tcpdump, etc. hanging around, and most > > annoyingly bound to ports. > > I guess you must have. Before that commit and especially before the cleanup mechanism it replaced, yes, definitely. > > So I find it very useful that it reliably cleans up after my debug / > > development mess. > > Ok, makes sense. > > > > It's not, of itself, a container tool. > > > > It's probably not. However, myself and others find it useful as > > "network container" tool, which doesn't have an exact definition, but > > it's nice to have as a "run a test and clean up all the traces" thing. > > > > It's more than a "network namespace connector" tool in that sense. If > > one needs just that, they'll probably use pasta without spawning a > > command anyway, together with an actual container tool. > > > > > > - for passt, to avoid possible attacks based on the knowledge of a > > > > target process' PID, but then I realised that would also apply to > > > > pasta's spawned process > > > > > > Right, for passt itself this is certainly worthwhile. If nothing else > > > it prevents passt sending a signal elswhere even if entirely > > > compromised. But we're not really trying to contain the spawned > > > process, other than for network purposes. > > > > Right, not in this case. > > I waould argue not in most cases, since, since the host fs is fully > exposed to the spawned command. > > > > > Isolating the filesystem would make it almost entirely useless for all > > > > the nice debugging / development features it offers (like running any > > > > network utility or test), but there's not much we would gain in a > > > > general case by keeping the original PID namespace (you don't use pasta > > > > to run strace or gdb), > > > > > > Not to run strace or gdb on something outside, no. But the PID > > > namespace makes it more hassle to do things to anything within it, > > > such as strace, gdb, kill or re-entering the namespace with nsenter. > > > > I never needed to do that with pasta spawning a command. But if it's a > > use case, this patch would cover that as well, and I guess giving > > --no-pidns in that case isn't that much of an overhead for something > > that looks like a corner case. > > Yeah, fair enough. The only downside I see is option bloat. Hmm yeah, but both modes look quite useful to me. Maybe it's time to categorise options in the usage message and in the man page as well. > > > > so I think it's an easy, albeit small, win from > > > > a security perspective. I'd rather keep it. > > > > > > For passt proper, yes. Isolating the spawned process doesn't seem > > > like it should be passt's concern - podman or bwrap would be much > > > better tools if that's what you want. > > > > Ah, sure, for the spawned process itself yes. -- Stefano