On Sun, 6 Sep 2026 15:17:58 +0200
Christian Korneck
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
Applied, thanks for the patch, and welcome to the git log! -- Stefano