From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202608 header.b=C+c2eDM1; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 069A85A0269 for ; Wed, 09 Sep 2026 08:07:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202608; t=1788934023; bh=buww4JG/kst+H8bgdochfPQYC3bZlkTbbRfwVAEb3B0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=C+c2eDM1BJ6w4gQu3SmZWvvodPQ+6piD/zlQ94iiUQiYXTn0oqxveJsrP+IlcGB8J 610QQQC3mCyQIPEZYaK5ySsjZkaejHEaYWALNxb9DRcfL6hswBoiCDHWa3UVZH5fky Gnj+WT5VCAcJKXVB6Xw+UJrcdUTIv25S7iWrIZqQ95LVjJUiUHhGBtEAoHqahK8vd6 yzs+JCqRk0PfVtbdcS8R64HMVfRPNJZdP/RkmDDG8dDsuX4alM1oGS2Xx1XvZNqBH2 JNsxoF/wrfPIfrAxR9P2TtihVFz+6bLX+tNu22uBCa/9hr5hMdLaIaL2DOuuW0RCei iZQsUE0R7U/mA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4hfr1M43TRz4wSc; Wed, 09 Sep 2026 16:07:03 +1000 (AEST) Date: Wed, 9 Sep 2026 16:00:25 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH] pasta: Add --no-pidns to keep spawned command in caller's PID namespace Message-ID: References: <20260906131758.121019-1-christian@korneck.de> <20260908114506.49f6ddd4@elisabeth> <20260908173233.429652e0@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+kaCoLHcxTGChhhT" Content-Disposition: inline In-Reply-To: <20260908173233.429652e0@elisabeth> Message-ID-Hash: J2OJNPU54C3KOT7TV3O2NSGCU5XN6CEJ X-Message-ID-Hash: J2OJNPU54C3KOT7TV3O2NSGCU5XN6CEJ X-MailFrom: dgibson@gandalf.ozlabs.org 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: --+kaCoLHcxTGChhhT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > > 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: > > > =20 > > > > On Sun, Sep 06, 2026 at 03:17:58PM +0200, Christian Korneck wrote: = =20 > > > > > This is to allow running pasta inside a container without unmaski= ng > > > > > /proc for the whole container (Docker's --security-opt > > > > > systempaths=3Dunconfined, Podman's --security-opt unmask=3DALL), = which is > > > > > undesirable as it exposes /proc/sysrq-trigger and other masked pa= ths. > > > > >=20 > > > > > In spawn mode, pasta clones the command with CLONE_NEWPID and mou= nts a > > > > > new procfs instance on /proc, so that it matches the new PID name= space. > > > > >=20 > > > > > Mounting procfs in a new user namespace requires a fully visible, > > > > > unobstructed procfs. Container runtimes deliberately obstruct /pr= oc > > > > > (Docker, for example, masks /proc/kcore and friends and mounts > > > > > /proc/sys read-only), so the mount is refused: > > > > >=20 > > > > > Couldn't mount /proc: Operation not permitted > > > > >=20 > > > > > We only warn and continue, leaving the command in a new PID names= pace > > > > > while the visible /proc still numbers processes in the outer one. > > > > > Anything resolving its own PID through /proc then fails, for exam= ple > > > > > bubblewrap: > > > > >=20 > > > > > bwrap: open /proc/22/ns/ns failed: No such file or directory > > > > >=20 > > > > > Add a --no-pidns option: skip CLONE_NEWPID for the spawned comman= d and > > > > > don't mount /proc, which is then not needed. User, network, mount= , UTS > > > > > and IPC namespaces, --config-net and port forwarding are unaffect= ed. > > > > > The option is rejected together with PID or --netns, as it only m= akes > > > > > sense when we spawn the command ourselves. > > > > >=20 > > > > > Add a test checking that, by default, the command runs in a new P= ID > > > > > namespace, and that --no-pidns keeps it in the caller's one. = =20 > > > >=20 > > > > 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 do= n't > > > > think we want to reimplement all of unshare(1) in pasta. =20 > > >=20 > > > 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. =20 > >=20 > > Fair point. > >=20 > > > The patch looks also pretty good and complete, so really low effort f= rom > > > my side. > > > =20 > > > > 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. > > > >=20 > > > > 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. =20 > > >=20 > > > The points are described in the message for 0515adceaa8f > > > ("passt, pasta: Namespace-based sandboxing, defer seccomp policy > > > application"): =20 > >=20 > > 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. >=20 > Ah, yeah, in that case it's just about cleaning up. >=20 > > > - no need to track child processes: when PID 1 exits, they all > > > terminate, instead of that crazy / buggy hack I implemented before > > > this change =20 > >=20 > > I guess. But is cleaning up the spawned process really pasta's job? >=20 > 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? > 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. > 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. >=20 > 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. >=20 > 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. >=20 > > > - 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 =20 > >=20 > > 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. >=20 > 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 pas= ta > > > to run strace or gdb), =20 > >=20 > > 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. >=20 > 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. > > > so I think it's an easy, albeit small, win from > > > a security perspective. I'd rather keep it. =20 > >=20 > > 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. >=20 > Ah, sure, for the spawned process itself yes. >=20 > --=20 > Stefano >=20 --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --+kaCoLHcxTGChhhT Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmqg9ekACgkQzQJF27ox 2Gda4g//diL9lLnbKir/dW3T+Ob3IlrmoaQ5Jq3kuqGQxwAjbfy0Zpip/CfGObyZ dx5pFKWYtlz4wUi0YTcaZaQ4JHyTtIlUJATfFB8knxOb+sv7JH58zkeZxMfA5B0x vJJqBccDWAuub7iLNKOqCLEt1M5iZgW9IxU1Pcl6KHLrXpFVePB/hN4BznTMuJcW a8QvNN4gzJejRXx4YHprTUn7NmtUnpva2l1DlLihCYmIENgJWgxSUEWVmlUPzf9Y SSVT6wY8xEsP+uQpWyZK5goQ9Bl5ircMSFVyY5o0fGKXRVV/u38xqPFt7ps0YFSU oNbE9Uyretucq4hpGEQfm9gPtl3SHxcjeHER9dtetrkIGjjpA0q3xlKvIxgEuVGJ rxazgjhJ/NFTSddZ17BXI5fyzobGY/lCRhwVN/ANVAY8354nWBlNFo5Gh4BP39Wp M1qCEKO1MnbGfkTNWYkmdX6DmpTEgYe7b9UQquexdhcCHMbPsj4DKEi2LjmSA/XO ZrMugBN6Xg03IaSfGQM5X5dr+SBnnKpHhvI+n154wkgeljyGGm8/oZqXoRXLetTF Y5KIggObtcqYoMCywina/3zoQfZ5dVMCa+Zg335mG6ybtAbLCBDnRPZFyiDb7cpb 0BF7UOmrksuAqt3+uZL4Ukh0D/b1BitfKGrxbKc9a54/nZF7LyI= =S0cP -----END PGP SIGNATURE----- --+kaCoLHcxTGChhhT--