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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 30, 2025 at 11:48 AM Willem de Bruijn
<willemdebruijn.kernel@xxxxxxxxx> wrote:
> stsp wrote:
> > 29.01.2025 17:12, Willem de Bruijn пишет:
> > > stsp wrote:
> > >> 29.01.2025 01:59, Willem de Bruijn пишет:
> > >>> stsp wrote:
> > >>>> 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.

If a revert is the best path forward for v6.14, do you think it would
be possible to get this fixed this week, or do you expect it to take
longer?

--
paul-moore.com





[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux