From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Brivio To: passt-dev@passt.top Subject: Re: [PATCH 8/8] Allow pasta to take a command to execute Date: Tue, 30 Aug 2022 19:41:55 +0200 Message-ID: <20220830194155.7fa069c2@elisabeth> In-Reply-To: <20220830102602.2bb8f2d3@elisabeth> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6875410961204755527==" --===============6875410961204755527== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 30 Aug 2022 10:26:02 +0200 Stefano Brivio wrote: > On Tue, 30 Aug 2022 11:16:05 +1000 > David Gibson wrote: >=20 > > On Mon, Aug 29, 2022 at 09:16:58PM +0200, Stefano Brivio wrote: =20 > > > On Fri, 26 Aug 2022 14:58:39 +1000 > > > David Gibson wrote: > > > =20 > > > > When not given an existing PID or network namspace to attach to, pasta > > > > spawns a shell. Most commands which can spawn a shell in an altered > > > > environment can also run other commands in that same environment, whi= ch can > > > > be useful in automation. > > > >=20 > > > > Allow pasta to do the same thing; it can be given an arbitrary comman= d to > > > > run in the network and user namespace which pasta creates. If neithe= r a > > > > command nor an existing PID or netns to attach to is given, continue = to > > > > spawn a default shell, as before. > > > >=20 > > > > Signed-off-by: David Gibson > > > > --- > > > > conf.c | 27 ++++++++++++++++++--------- > > > > passt.1 | 14 +++++++++----- > > > > pasta.c | 33 +++++++++++++++++++++++---------- > > > > pasta.h | 2 +- > > > > 4 files changed, 51 insertions(+), 25 deletions(-) > > > >=20 > > > > diff --git a/conf.c b/conf.c > > > > index 2a18124..162c2dd 100644 > > > > --- a/conf.c > > > > +++ b/conf.c > > > > @@ -550,7 +550,8 @@ static int conf_ns_pid(char *userns, char *netns,= const char *arg) > > > > return 0; > > > > } > > > > =20 > > > > - return -EINVAL; > > > > + /* Not a PID, later code will treat as a command */ > > > > + return 0; > > > > } > > > > =20 > > > > /** > > > > @@ -1480,14 +1481,18 @@ void conf(struct ctx *c, int argc, char **arg= v) > > > > =20 > > > > check_root(c); > > > > =20 > > > > - if (c->mode =3D=3D MODE_PASTA && optind + 1 =3D=3D argc) { > > > > - ret =3D conf_ns_pid(userns, netns, argv[optind]); > > > > - if (ret < 0) > > > > + if (c->mode =3D=3D MODE_PASTA) { > > > > + if (*netns && optind !=3D argc) { > > > > + err("Both --netns and PID or command given"); > > > > usage(argv[0]); > > > > - } else if (c->mode =3D=3D MODE_PASTA && *userns > > > > - && !*netns && optind =3D=3D argc) { > > > > - err("--userns requires --netns or PID"); > > > > - usage(argv[0]); > > > > + } else if (optind + 1 =3D=3D argc) { > > > > + ret =3D conf_ns_pid(userns, netns, argv[optind]); > > > > + if (ret < 0) > > > > + usage(argv[0]); > > > > + } else if (*userns && !*netns && optind =3D=3D argc) { > > > > + err("--userns requires --netns or PID"); > > > > + usage(argv[0]); > > > > + } > > > > } else if (optind !=3D argc) { > > > > usage(argv[0]); > > > > } > > > > > > > > [...] =20 > > >=20 > > > I haven't really looked into this yet, but I guess we should now > > > handle getopts return codes a bit differently, because this works: > > >=20 > > > $ ./pasta --config-net -- sh -c 'sleep 1; ip li sh' > > > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN m= ode DEFAULT group default qlen 1000 > > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > > 2: enp9s0: mtu 65520 qdisc pfifo_fa= st state UNKNOWN mode DEFAULT group default qlen 1000 > > > link/ether aa:3e:39:5f:c6:15 brd ff:ff:ff:ff:ff:ff > > >=20 > > > while this doesn't: > > >=20 > > > $ ./pasta --config-net sh -c 'sleep 1; ip li sh' > > > ./pasta: invalid option -- 'c' > > > [...] > > >=20 > > > despite the fact that there's no ambiguity. =20 > >=20 > > You mean because pasta itself doesn't have a -c option? =20 >=20 > Ah, no, I meant it's after 'sh', which is a non-option argument. > However, >=20 > > Attempting to > > account for that sounds like a bad idea. Requiring -- when the > > command given has options of its own that aren't supposed to go to the > > wrapper is pretty common for these sorts of tools. Basically the > > trade-off is that you either need to require that, or you have to > > require that all non-option arguments of the wrapper come last (old > > style POSIXish command line parsing, as opposed to GNUish > > conventions). The latter is usually more awkward than the former. =20 >=20 > ...right, my assumption was exactly that, but it's probably not a good > one. Let's keep it this way then. I wonder, though, if in the man page: >=20 > pasta [OPTION]... [COMMAND [ARG]...] >=20 > we should explicitly mention this, because from this synopsis line it > looks like it's enough to put any command, with any argument, at the > end. Or maybe it's already covered by typical GNUish conventions and > users are used to it. ...I couldn't find any example of an explicit mention of "--" in man pages, so I'm not sure what's the convention for this, if any. I'd leave the man page as you patched it, if somebody has a better idea or stumbles upon this, we can improve it later. --=20 Stefano --===============6875410961204755527==--