Re: [PATCH] pasta: Add --no-pidns to keep spawned command in caller's PID namespace

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 7242 bytes --]

On Tue, Sep 08, 2026 at 05:32:34PM +0200, Stefano Brivio wrote:
> On Tue, 8 Sep 2026 21:09:36 +1000
> David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> 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?

> 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.
> 
> 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.

> > > 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
> 

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]