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

[Stefano Brivio <sbrivio@redhat.com>]

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.

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.

So I find it very useful that it reliably cleans up after my debug /
development mess.

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

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

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