passt, branch 2023_06_25.32660ce

pasta: include errno in error message

2023-06-25T21:50:42+00:00

When the open() or setns() calls fails pasta exits early and prints an
error. However it did not include the errno so it was impossible to know
why the syscall failed.

Signed-off-by: Paul Holzinger 
Reviewed-by: David Gibson 
[sbrivio: Split print to fit 80 columns in pasta_open_ns()]
Signed-off-by: Stefano Brivio

isolation: keep CAP_SYS_PTRACE when required

2023-06-25T21:49:25+00:00

When pasta is started from an existing userns and tries to join the
netns from another process it fails to open /proc/$pid/ns/net due the
missing CAP_SYS_PTRACE capability in the --netns-only case.

A simple reproducer for this.
First create a userns:
$ unshare -r

Then create a new netns inside it and try to join that netns with pasta.
$ unshare -n sleep inf &
$ pasta --config-net --netns /proc/$!/ns/net

Signed-off-by: Paul Holzinger 
Signed-off-by: Stefano Brivio

conf: Accept -a and -g without --config-net in pasta mode

2023-06-25T21:49:25+00:00

While --no-copy-addrs and --no-copy-routes only make sense with
--config-net, and they are implied on -g and -a, respectively, that
doesn't mean we should refuse -a or -g without --config-net: they are
still relevant for a number of things (including DHCP/DHCPv6/NDP
configuration).

Reported-by: Gianluca Stivan 
Fixes: cc9d16758be6 ("conf, pasta: With --config-net, copy all addresses by default")
Fixes: da54641f140e ("conf, pasta: With --config-net, copy all routes by default")
Signed-off-by: Stefano Brivio

conf: Make -a/--address really imply --no-copy-addrs

2023-06-25T21:49:25+00:00

I wrote it in commit message and man page, but not in conf()...

Note that -g/--gateway correctly implies --no-copy-routes already.

This fixes Podman's tests:

  podman networking with pasta(1) - IPv4 address assignment
  podman networking with pasta(1) - IPv4 default route assignment

where we pass -a and -g to assign an address and a default gateway
that's compatible with it, but -a doesn't disable the copy of
addresses, so we ignore -a, and the default gateway is incompatible
with the addresses we copy -- hence no routes in the container.

Link: https://github.com/containers/podman/pull/18612
Fixes: cc9d16758be6 ("conf, pasta: With --config-net, copy all addresses by default")
Signed-off-by: Stefano Brivio

seccomp: Make seccomp.sh re-entrancy safe

2023-06-25T21:49:11+00:00

seccomp.sh generates seccomp.h piece by piece using >> directives.  This
means that if two instances of seccomp.h are run concurrently a corrupted
version of seccomp.h will be generated. Amongst other problems this can
cause spurious failures on clang-tidy.

Alter seccomp.sh to build the output in a temporary file and atomic move it
to seccomp.h, so concurrent invocations will still result in valud output.

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

conf, log: On -h / --help, print usage to stdout, not stderr

2023-06-23T08:15:55+00:00

Erik suggests that this makes it easier to grep for options, and with
--help we're anyway printing usage information as expected, not as
part of an error report.

While at it: on -h, we should exit with 0.

Reported-by: Erik Sjölund 
Link: https://bugs.passt.top/show_bug.cgi?id=52
Link: https://bugs.passt.top/show_bug.cgi?id=53
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

tap: With pasta, don't reset on tap errors, handle write failures

2023-06-23T08:15:10+00:00

Since commit 0515adceaa8f ("passt, pasta: Namespace-based sandboxing,
defer seccomp policy application"), it makes no sense to close and
reopen the tap device on error: we don't have access to /dev/net/tun
after the initial setup phase.

If we hit ENOBUFS while writing (as reported: in one case because
the kernel actually ran out of memory, with another case under
investigation), or ENOSPC, we're supposed to drop whatever data we
were trying to send: there's no room for it.

Handle EINTR just like we handled EAGAIN/EWOULDBLOCK: there's no
particular reason why sending the same data should fail again.

Anything else I can think of would be an unrecoverable error: exit
with failure then.

While at it, drop a useless cast on the write() call: it takes a
const void * anyway.

Reported-by: Gianluca Stivan 
Reported-by: Chris Kuhn 
Fixes: 0515adceaa8f ("passt, pasta: Namespace-based sandboxing, defer seccomp policy application")
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

conf: Fix erroneous check of ip6->gw

2023-06-03T05:49:17+00:00

a7359f094898 ("conf: Don't exit if sourced default route has no gateway")
was supposed to allow passt/pasta to run even if given a template interface
which has no default gateway.  However a mistake in the patch means it
still requires the gateway, but doesn't require a global address for the
guest which we really do need.

This is one part (but not the only part) of the problem seen in
https://bugs.passt.top/show_bug.cgi?id=50.

Reported-by: Justin Jereza 
Fixes: a7359f094898 ("conf: Don't exit if sourced default route has no gateway")
Link: https://bugs.passt.top/show_bug.cgi?id=50
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

test/nstool: Fix fd leak in accept() loop

2023-05-23T15:06:32+00:00

nstool loops on accept(), but failed to close the accepted socket fds
before continuing on.  So, with repeated commands it would eventually die
with an EMFILE.

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

test/nstool: Provide useful error if given a path that's too long

2023-05-23T15:06:29+00:00

Normal filesystem paths can be very long (PATH_MAX is around 8k), however
Unix domain sockets can only use relatively short paths (UNIX_PATH_MAX is
108 on Linux).  Currently nstool will simply truncate paths that are too
long, leading to difficult to understand failures.

Make such failures clearer, with an explicit error message if given a path
that's too long.

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