passt/test/pasta_options/no_pidns, branch master Plug A Simple Socket Transport pasta: Add --no-pidns to keep spawned command in caller's PID namespace 2026-09-16T08:54:02+00:00 Christian Korneck christian@korneck.de 2026-09-06T13:17:58+00:00 588b545dae741bec6fd7622a33c7852c06d72a59 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. Signed-off-by: Christian Korneck <christian@korneck.de> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
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.

Signed-off-by: Christian Korneck <christian@korneck.de>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>