From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefano Brivio <sbrivio@redhat.com>
To: passt-dev@passt.top
Subject: Re: [PATCH v2 10/10] Allow --userns when pasta spawns a command
Date: Sat, 10 Sep 2022 22:42:18 +0200
Message-ID: <20220910224218.0a4ba54a@elisabeth>
In-Reply-To: <Yxw830V/uIMd1bzY@yekko>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0399019103150054194=="

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

On Sat, 10 Sep 2022 17:29:35 +1000
David Gibson <david(a)gibson.dropbear.id.au> wrote:

> On Fri, Sep 09, 2022 at 04:34:25PM +0200, Stefano Brivio wrote:
> > On Thu,  8 Sep 2022 13:59:07 +1000
> > David Gibson <david(a)gibson.dropbear.id.au> wrote:
> >  =20
> > > Currently --userns is only allowed when pasta is attaching to an existi=
ng
> > > netns or PID, and is prohibited when creating a new netns by spawning a
> > > command or shell.
> > >=20
> > > With the new handling of userns, this check isn't neccessary.  I'm not =
sure
> > > if there's any use case for --userns with a spawned command, but it's
> > > strictly more flexible and requires zero extra code, so we might as wel=
l. =20
> >=20
> > I think it's helpful because one might not be able to join a network
> > namespace without first joining a given user namespace. =20
>=20
> Well.. this is strictly for the spawning command case, so we're
> creating the network ns rather than joining one.

Ah, you're right. Then I'm also not sure. But yes, it's negative lines
of code, so why not.

--=20
Stefano


--===============0399019103150054194==--