From: Jakub Kicinski <kuba@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, shuah@kernel.org, petrm@nvidia.com,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next v5 0/7] selftests: drv-net: support testing with a remote system
Date: Wed, 24 Apr 2024 11:57:12 -0700 [thread overview]
Message-ID: <20240424115712.37d27b05@kernel.org> (raw)
In-Reply-To: <66291395c0468_1a76072943e@willemb.c.googlers.com.notmuch>
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@machine"
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.
next prev parent reply other threads:[~2024-04-24 18:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-20 2:52 [PATCH net-next v5 0/7] selftests: drv-net: support testing with a remote system Jakub Kicinski
2024-04-20 2:52 ` [PATCH net-next v5 1/7] selftests: drv-net: define endpoint structures Jakub Kicinski
2024-04-20 2:52 ` [PATCH net-next v5 2/7] selftests: drv-net: factor out parsing of the env Jakub Kicinski
2024-04-20 2:52 ` [PATCH net-next v5 3/7] selftests: drv-net: construct environment for running tests which require an endpoint Jakub Kicinski
2024-04-20 2:52 ` [PATCH net-next v5 4/7] selftests: drv-net: add a trivial ping test Jakub Kicinski
2024-04-20 2:52 ` [PATCH net-next v5 5/7] selftests: net: support matching cases by name prefix Jakub Kicinski
2024-04-20 2:52 ` [PATCH net-next v5 6/7] selftests: drv-net: add a TCP ping test case (and useful helpers) Jakub Kicinski
2024-04-20 2:52 ` [PATCH net-next v5 7/7] selftests: drv-net: add require_XYZ() helpers for validating env Jakub Kicinski
2024-04-21 14:59 ` Willem de Bruijn
2024-04-21 14:47 ` [PATCH net-next v5 0/7] selftests: drv-net: support testing with a remote system Willem de Bruijn
2024-04-23 17:57 ` Willem de Bruijn
2024-04-24 1:53 ` Jakub Kicinski
2024-04-24 14:13 ` Willem de Bruijn
2024-04-24 18:57 ` Jakub Kicinski [this message]
2024-04-24 20:59 ` Willem de Bruijn
2024-04-23 17:20 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240424115712.37d27b05@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=shuah@kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).