From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefano Brivio <sbrivio@redhat.com>
To: passt-dev@passt.top
Subject: Re: [PATCH] RFC: Remove unusable --netns-only option
Date: Tue, 19 Jul 2022 22:39:25 +0200
Message-ID: <20220719223925.617bdb92@elisabeth>
In-Reply-To: <20220719062310.604168-1-david@gibson.dropbear.id.au>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7921916651358011022=="

--===============7921916651358011022==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 19 Jul 2022 16:23:10 +1000
David Gibson <david(a)gibson.dropbear.id.au> wrote:

> The intended semantics of --netns-only are pretty unclear to me.  It's
> intended for pasta, but it's not clear whether its saying the spawned shell
> should only enter the target netns, or that the passt/pasta packet
> forwarding process should only sandbox itself in a network namespace, not
> a user namespace.

The latter. I think this is marginally more clear in the man page, but needs
indeed a better explanation.

> In any case, as far as I can tell there's not actually any case in which
> the --netns-only option will work.  If nothing else, we will always fail
> in sandbox(), because it attempts a number of operations which require
> CAP_SYS_ADMIN in our current user namespace.  We drop all capabilities in
> our initial user namespace when we start, so the only way we can have
> CAP_SYS_ADMIN at this point is if we've joined a new user namespace, which
> we won't do with --netns-only.
>=20
> For pasta joining an existing namespace (the apparently intended use case),=
 we'll actually fail before
> we'll fail before we get to that point: in conf_ns_check() we'll attempt
> to join the target network namespace.  This also requires CAP_SYS_ADMIN in
> both our current user namespace and the user namespace which owns the
> target network namespace.  Again, since we've dropped capabilities in our
> original namespace this will never be the case.

...however, we can also have UID 0 in a non-init user namespace, and
that will work.

This is what happens in the Podman integration case. Unfortunately the
demo is broken at the moment (I had to rebase the patch with a bit of
care, I'll publish the updated one soon).

> For pasta creating its own network namespace we'll fail for a similar
> reason in yet another place.  This time we'll fail in nl_sock_init() again
> because we attempt to enter the new network ns via NS_CALL without having
> regained CAP_SYS_ADMIN by joining a new user namespace.  Because this
> happens after spawning the shell, it results in a weird failure mode, where
> the pasta spawned shell is running, but pasta isn't actually handling
> packets.  Exiting the shell will lead to a hang until the process is
> explicitly killed.

Ouch, I didn't think of this.

Anyway, let me get back to you in a couple of days on the whole issue.
The usage is there, albeit poorly documented, with a broken demo, and
no handling of (kind of) corner cases.

--=20
Stefano


--===============7921916651358011022==--