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: 4853 bytes --]

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.

> - 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?
It's not, of itself, a 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.

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

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

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