From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: stsp <stsp2@yandex.ru>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
pabeni@redhat.com, jasowang@redhat.com,
Willem de Bruijn <willemb@google.com>,
Ondrej Mosnacek <omosnace@redhat.com>
Subject: Re: [PATCH net] tun: revert fix group permission check
Date: Mon, 03 Feb 2025 14:09:11 -0500 [thread overview]
Message-ID: <67a114574eee7_2f0e52948e@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <48edf7d4-0c1f-4980-b22f-967d203a403d@yandex.ru>
stsp wrote:
> 03.02.2025 18:05, Willem de Bruijn пишет:
> > From: Willem de Bruijn <willemb@google.com>
> >
> > This reverts commit 3ca459eaba1bf96a8c7878de84fa8872259a01e3.
> >
> > The blamed commit caused a regression when neither tun->owner nor
> > tun->group is set. This is intended to be allowed, but now requires
> > CAP_NET_ADMIN.
> >
> > Discussion in the referenced thread pointed out that the original
> > issue that prompted this patch can be resolved in userspace.
>
> The point of the patch was
> not to fix userspace, but this
> bug: when you have owner set,
> then adding group either changes
> nothing at all, or removes all
> access. I.e. there is no valid case
> for adding group when owner
> already set.
As long as no existing users are affected, no need to relax this after
all these years.
It is up to users to not choose an overly restrictive setting, similar
to how they should not set chmod a-rwx on a file.
A user will immediately find out if they mess up this configuration,
and it takes extra steps (ioctls) to reach it, so is unlikely to be
reached by accident.
> During the discussion it became
> obvious that simpler fixes may
> exist (like eg either-or semantic),
> so why not to revert based on
> that?
We did not define either-or in detail. Do you mean failing the
TUNSETOWNER or TUNSETGROUP ioctl if the other is already set? That
could break existing users that set both.
> > The relaxed access control may now make a device accessible when it
> > previously wasn't, while existing users may depend on it to not be.
> >
> > Since the fix is not critical and introduces security risk, revert,
> Well, I don't agree with that justification.
> My patch introduced the usability
> problem, but not a security risk.
> I don't want to be attributed with
> the security risk when this wasn't
> the case (to the very least, you
> still need the perms to open /dev/net/tun),
> so could you please remove that part?
> I don't think you need to exaggerate
> anything: it introduces the usability
> regression, which should be enough
> for any instant revert.
This is not intended to cast blame, of course.
That said, I can adjust the wording.
The access control that we relaxed is when a process is not allowed
to access a device until the administrator adds it to the right group.
Is this used? I doubt it. But we cannot be sure.
next prev parent reply other threads:[~2025-02-03 19:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 15:05 [PATCH net] tun: revert fix group permission check Willem de Bruijn
2025-02-03 18:14 ` stsp
2025-02-03 19:09 ` Willem de Bruijn [this message]
2025-02-03 19:30 ` stsp
2025-02-03 22:54 ` Willem de Bruijn
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=67a114574eee7_2f0e52948e@willemb.c.googlers.com.notmuch \
--to=willemdebruijn.kernel@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=omosnace@redhat.com \
--cc=pabeni@redhat.com \
--cc=stsp2@yandex.ru \
--cc=willemb@google.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