Thread (19 messages) 19 messages, 4 authors, 2025-02-06

Re: Possible mistake in commit 3ca459eaba1b ("tun: fix group permission check")

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2025-01-30 16:46:29
Also in: netdev, selinux

stsp wrote:
29.01.2025 17:12, Willem de Bruijn пишет:
quoted
stsp wrote:
quoted
29.01.2025 01:59, Willem de Bruijn пишет:
quoted
stsp wrote:
quoted
By doing that you indeed avoid
the problem of "completely
inaccessible tap". However, that
breaks my setup, as I really
intended to provide tap to the
owner and the unrelated group.
This is because, eg when setting
a CI job, you can add the needed
user to the needed group, but
you also need to re-login, which
is not always possible. :(
Could you leave tun->owner unset?
That's exactly the problem: when
the user is not in the needed group,
then you need to unset _both_.
Unsetting only owner is not enough.
Adding the user to the group is not
enough because then you need to
re-login (bad for CI jobs).
At some point we can question whether the issue is with the setup,
rather than the kernel mechanism.

Why does your setup have an initial user that lacks the group
permissions of the later processes, and a tun instance that has both
owner and group constraints set?

Can this be fixed in userspace, rather than allow this odd case in the
kernel. Is it baked deeply into common containerization tools, say?
No-no, its not a real or unfixible
problem. At the end, I can just
drop both group and user ownership
of the TAP, and simply not to care.
In that case the safest course of action is to revert the patch.

It relaxes some access control restrictions that other users may have
come to depend on.

Say, someone expects that no process can use the device until it
adds the user to one of the groups.

It's farfetched, but in cases of access control, err on the side of
caution. Especially retroactively.
My aforementioned attempt to
allow changing suppl groups, was
not directed to this particular case -
inability to change suppl groups
create much bigger problems in
other areas, but my TAP problem
is really very small.
Which is why, eg if you decide to
use "either-or" semantic - fine with
me. I just think that completely
reverting the patch is a sub-optimal
choice, as the previous situation
was even more broken than now.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help