passt/conf.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

parse: Convert parse_mac() to conventions of parse.c

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

parse_mac() predates parse.c and doesn't obey the same conventions it now
uses.  Convert it to work similarly to the other functions in parse.c.

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

conf, fwd: Prefer same-scope address as inbound source address from host

2026-07-28T16:09:27+00:00

We might have situations, such as the one described in
https://bugs.passt.top/show_bug.cgi?id=217, where using a link-local
address as source in a given namespace doesn't guarantee that we can
reach the intended destination, because, for instance, the inbound
traffic we forward is in turn forwarded to a different interface, such
as a bridge.

In that case, the assumption from 9618d247006a ("ndp, dhcpv6, tcp,
udp: Always use link-local as source if gateway isn't") isn't a safe
one: the user might have specified a valid gateway address, matching
the scope of the destination address, but we won't use it as address
of last resort, and prefer a link-local address with a mismatch in
scope instead.

So, if the user specifies a given default gateway address for IPv6,
note that as 'our_tap_addr', like we would do with with IPv4, and
stick to Rule 2 of RFC 6724, Section 5, when selecting a source
address, by preferring an address with the same scope, if available.

Note that this preference will be applied only if, at the point of
the source address selection, the destination address is already
known, which, in general, only happens if there's an explicit mapping
rule specifying the target destination address.

Otherwise, if there's no explicit rule picking the destination
address, we select the destination address after selecting the source
address. This should probably be improved at some point, to select
matching address pairs (when a compatible one is available) instead of
sequentially picking source and destination addresses. That appears to
be beyond the scope of this patch, though.

Reported-by: Paul Holzinger 
Link: https://bugs.passt.top/show_bug.cgi?id=217
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

conf: Honour --address, --gateway, --netmask in local mode as well

2026-07-28T16:01:00+00:00

When I implemented local mode in 14b84a7f077e ("treewide: Introduce
'local mode' for disconnected setups"), I didn't consider the
possibility that, also in that case, the user might want to override
addresses, default gateway or netmask, even though I expressly
mentioned this in the man page:

  In this case, **unless configured otherwise**, they will assign the
  IPv4 link-local address 169.254.2.1 to the guest or target
  namespace, and no IPv6 address.

Fix this by checking if an address, gateway, or netmask length was
explicitly set by the user, before overriding them with the default
parameters for local mode.

This might lead to invalid configurations where we won't be able to
set the default gateway passed by the user, but we print a warning
message, and we assume users know what they're doing in that case.

Link: https://bugs.passt.top/show_bug.cgi?id=217
Fixes: 14b84a7f077e ("treewide: Introduce 'local mode' for disconnected setups")
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

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

isolation: Move --fd descriptor to a number of our choosing

2026-07-18T07:54:31+00:00

Some users of passt pass an fd for the tap interface in, with the --fd
parameter, rather than having passt open it itself.  This requires some
slightly fiddly logic in isolate_fds() so we don't close() it along with
any other file descriptors leaked into us by the parent.

More importantly, this is broken if the passed fd is 0, 1 or 2, since in
that case we will assume it's a standard stream and close it in __daemon().
We explicitly disallow 1 or 2 in conf_tap_fd(), but 0 has been permitted
since aa1cc8922 ("conf: allow --fd 0").  It looks like the use case of the
contributor of that patch didn't involve daemonizing passt.

To fix this more robustly, use dup2() to move to the passed fd to 3.  This
removes the possibility of mixing it up with a standard stream, and as a
bonus makes the close_range() logic much simpler.  With isolate_fds() made
safe for --fd 1 and --fd 2, we can remove the logic excluding those from
conf_fd_tap().

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

conf: Make conf_tap_fd() operate more like conf_mode()

2026-07-18T07:54:29+00:00

We have two cases where we need to parse specific options early:
conf_tap_fd() and conf_mode().  conf_tap_fd() has a slightly odd interface,
requiring the caller to use getopt_long() to find the right option, then
pass it in.  Alter it to work like conf_mode() instead, where all the
command line parsing logic is contained within the conf.c function.

This is slightly more lines, but has a clearer division of responsibility.

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

isolation, conf: Set c->fd_tap from early parse of --fd

2026-07-18T07:54:27+00:00

We parse --fd twice: once in isolate_initial() just to avoid clobbering
the passed in fd.  Then we parse it "for real" in conf(), to set c->fd_tap
and other configuration variables.

Change this, so that we return the value parsed early from
isolate_initial() and set c->fd_tap from that.  This doesn't accomplish
much immediately, but will make some further cleanups possible.

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

fwd: Clarify semantics of --host-lo-to-ns-lo

2026-07-14T23:22:40+00:00

The semantics of --host-lo-to-ns-lo as described in the man page don't
quite make sense: It says without the option forwarded packets will appear
to come _from_ the guest's public address, which is not usually true.
Instead the packets will arrive *to* the guest's public address.  The exact
semantics are also a bit confusing in general.

Rewrite both the man page and code to clarify this.  The new rule is that
it redirects connections addressed to a host loopback address to the same
loopback address in the guest.  This is notionally different from what we
had in two ways:
  * We can now deliver to nonstandard loopback addresses within the guest,
    not just the default one.  This is technically a behavioural change,
    but I think will be less surprising behaviour.
  * The decision is now made on the original _destination_ address, rather
    than source address.  That's different theoretically, but not in
    practice, since loopback packets must have loopback addresses for both
    source and destination.

We make it explicitly incompatible with --no-splice - previously it
was allowed, but would have no effect in that case.

As well as being more precise right now, these semantics will intersect
better with other upcoming changes to the forwarding logic.

Link: https://bugs.passt.top/show_bug.cgi?id=212
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio