passt/pasta.c, branch 2026_09_25.df90211

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

2026-09-16T08:54:02+00:00

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 
Signed-off-by: Stefano Brivio

util, pasta: Remove some unneeded #includes

2026-09-08T14:11:28+00:00

Presumably these mattered at some point in the past, but no longer.  Found
by clangd as invoked by Zed editor.  Not sure why direct clang-tidy runs
didn't spot these.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

isolation: Don't create our userns as nobody

2026-09-08T14:00:23+00:00

In isolate_user(), we set[ug]id() to our final UID/GID, then join or
create our userns.  This makes sense when we're going to use an already
existing userns, that is, with the --userns option, a PID passed to pasta
or with --netns-only (we use our current userns).  However, it causes a
problem when we create our own new userns.

The set[ug]id() is most often a no-op, but when it isn't it's generally a
switch from root to nobody.  If we create our userns after this, we will
create it owned by nobody.  That means that anything which can operate as
nobody can enter our userns with full capabilities, potentially allowing
it to attack a running passt or pasta.  This sort of attach is unlikely
in practice: something else on the system must have a security defect to
allow arbitrary actions as nobody, and even then it will probably be caught
by LSMs.

Still, it's better to avoid this.  So, rearrange the creation of our
userns so that it is owned by the original user (e.g. root).  This requires
us to always create a UID & GID mapping within the userns so that we can
switch to the correct final user after we've entered the namespace.

Since we now always create that user mapping when we create the ns, we no
longer need to do so as we spawn the pasta shell or command.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

util, pasta: Generalise [ug]id_map creation

2026-09-08T14:00:19+00:00

pasta_start_ns() creates UID and GID mappings for the user namespace in
which the child process runs.  We're going to want some more flexible
variants of this, so move it into a more general helper function
make_ugid_map() which will make a single user UID/GID mapping for the
userns owned by a given PID.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

pasta: Include pasta.h in pasta.c

2026-09-08T14:00:05+00:00

pasta.c doesn't include its own header, meaning the compiler hasn't caught
some mismatches between functions and their prototypes.  Fix the oversight.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

pasta: Do not configure ID mappings when invoked with --netns-only

2026-07-23T09:46:49+00:00

Add a `bool` argument `config_idmaps` to `pasta_start_ns()` that guards
the logic to configure user and group ID mappings. It is set to `false`
when `netns_only` is `true`. Fixes bug 216.

Link: https://bugs.passt.top/show_bug.cgi?id=216
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Dwayne B. Bent 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

pesto, log: Share log.h (but not log.c) with pesto tool

2026-05-07T06:06:30+00:00

In pesto we're going to want several levels of error/warning messages, much
like passt itself.  Particularly as we start to share mode code between
passt and pesto, we want to use a similar interface to emit those.  However
we don't want to use the same implementation - logging to a file or syslog
doesn't make sense for the command line tool.

To accomplish this loosely share log.h, but not log.c between pesto and
passt.  In fact, an #ifdef means even most of log.h isn't actually shared,
but we do provide similar warn(), die() etc. macros.

This includes the *_perror() variants, which need strerror().  However,
we want to avoid allocations for pesto as we do for passt, and strerror()
allocates in some libc versions.  Therefore, also move our workaround for
this to be shared with pesto.

Reviewed-by: Laurent Vivier 
[dwg: Based on changes part of a larger patch by Stefano]
Signed-off-by: David Gibson 
[sbrivio: Dropped debug_perror_() as it's not used anyway, Laurent was
 asking about its name]
[sbrivio: Fix conflicts in the Makefile caused by the fact that I'm
 not merging a previous series reworking it]
[sbrivio: For some reason, this triggers some unrelated, but valid,
 cppcheck warnings in tap.c and conf.c: fix / suppress them]
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

conf, pasta: Add --splice-only option

2026-01-19T08:12:27+00:00

This patch introduces a mode where we only forward loopback connections
and traffic between two namespaces (via the loopback interface, 'lo'),
without a tap device.

It might be used to fix up podman IPv4 / IPv6 loopback mapping when using
rootlesskit for forwarding ports, or a way to implement isolated containers.

In this mode, --host-lo-to-ns-lo and --no-icmp are automatically enabled.
Option --no-splice is rejected.

Link: https://bugs.passt.top/show_bug.cgi?id=149
Signed-off-by: Yumei Huang 
Signed-off-by: Stefano Brivio

pasta: Warn, disable matching IP version if not supported, in local mode

2025-12-23T14:10:02+00:00

...instead of exiting, but only if local mode is enabled, that is, if
we couldn't find a template interface or if the user didn't specify
one.

With IPv4, we always try to set or copy an address, so check if that
fails.

With IPv6, in local mode, we rely on the link-local address that's
automatically generated inside the target namespace, and only fail
later, as we try to set up routes. Check if that fails, instead.

Otherwise, we'll fail to start if IPv6 support is not built in or
disabled by the kernel ("ipv6.disable=1" on the command line),
because, in that case, we'll try to enable local mode by default, and
then fail to set any address or route.

It would probably be more elegant to check for IP version support in
conf_ip4_local() and conf_ip6_local(), and not even try to enable
connectivity for unsupported versions, but it looks less robust than
trying and failing, as there might be other ways to disable a given
IP version.

Note that there's currently no way to disable IPv4 support on the
kernel command line, that is, there's no such thing as an
ipv4.disable boot parameter. But I guess that's due to be eventually
implemented, one day, so let's cover that case as well, also for
consistency.

Reported-by: Iyan 
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2424192
Fixes: 4ddd59bc6085 ("conf: Separate local mode for each IP version, don't enable disabled IP version")
Signed-off-by: Stefano Brivio

pasta: Clean up waiting pasta child on failures

2025-12-12T21:23:14+00:00

When pasta is invoked with a command rather than an existing namespace to
attach to, it spawns a child process to run a shell or other command.  We
create that process during conf(), since we need the namespace to exist for
much of our setup.  However, we don't want the specified command to run
until the pasta network interface is ready for use.  Therefore,
pasta_spawn_cmd() executing in the child waits before exec()ing.  main()
signals the child to continue with SIGUSR1 shortly before entering the
main forwarding loop.

This has the downside that if we exit due to any kind of failure between
conf() and the SIGUSR1, the child process will be around waiting
indefinitely.  The user must manually clean this up.

Make this cleaner, by having the child use PR_SET_PDEATHSIG to have
itself killed if the parent dies during this window.  Technically
speaking this is racy: if the parent dies before the child can call
the prctl() it will be left zombie-like as before.  However, as long
as the parent completes pasta_wait_for_ns() before dying, I wasn't
able to trigger the race.  Since the consequences of this going wrong
are merely a bit ugly, I think that's good enough.

Suggested-by: Paul Holzinger 
Signed-off-by: David Gibson 
Reviewed-by: Paul Holzinger 
Signed-off-by: Stefano Brivio