[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <662972bd69700_1b61b92949@willemb.c.googlers.com.notmuch>
Date: Wed, 24 Apr 2024 16:59:41 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jakub Kicinski <kuba@...nel.org>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net,
netdev@...r.kernel.org,
edumazet@...gle.com,
pabeni@...hat.com,
shuah@...nel.org,
petrm@...dia.com,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v5 0/7] selftests: drv-net: support testing with
a remote system
Jakub Kicinski wrote:
> On Wed, 24 Apr 2024 10:13:41 -0400 Willem de Bruijn wrote:
> > > I haven't thought about this part much, TBH. I'm not aware of any
> > > scheme used in other tests.
> > > IIUC the problem is that we need root locally, and then try to SSH
> > > over to remote. But normally the SSH keys belong to the non-root
> > > user, so SSH'ing as root is annoying?
> >
> > Yeah. It requires "PermitRootLogin yes" in your sshd_config and
> > installing root keys.
> >
> > It's not a huge issue, but if we do want to fix it, doing so will be
> > easier early rather than when more tests are added with implicit
> > dependency on having root.
>
> You know what, we need a diagram. We currently expect:
>
>
> ------------ -------------
> | | | |
> | Local user | ---------->| Remote user |
> | | / | |
> ------------ / -------------
> /
> /
> ------------ / -------------
> | >*exec*< | / | |
> | Local root |-------------U---------------->| Remote root |
> | | ? | |
> ------------ -------------
>
>
> We run locally as root. Putting sudo on all local commands would be
> annoying.
>
> On remote we don't currently explicitly say whether we need root.
> The user is basically implicitly controlled by the REMOTE_ARGS
> and ssh config.
>
> REMOTE_ARGS="john@...hine"
>
> will make us log in as john. But *from* root, so pub key of root needs
> to be deployed.
>
> We can support:
>
> ------------ -------------
> | | | |
> | Local user | ? | Remote user |
> | ,--------------------U-------------->| |
> ------/-----` \ -------------
> | ?su back to user? \
> | \
> ------------ \ -------------
> | >*exec*< | \ | |
> | Local root | `--------->| Remote root |
> | | | |
> ------------ -------------
>
> but it's unclear whether that's all you're asking for, or also:
>
> ------------ -------------
> | | | |
> | Local user | | Remote user |
> | ,----------------------------------->->?cond sudo? |
> ------/-----` -----|-------
> | su back to user |
> | |
> ------------ -----v-------
> | >*exec*< | | |
> | Local root | | Remote root |
> | | | |
> ------------ -------------
>
> which would require us to annotate privileged remote commands.
For many tests the peer traffic generator/sink will not need to be
root.
But I already see some counter-examples, such as the PF_PACKET
packet generation on the transmitter for checksum receive tests.
Powered by blists - more mailing lists