On Tue, Feb 4, 2025 at 1:30 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > 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? Willem has already posted patches on netdev [1][2] (thanks!), so I expect it will be fixed soon. [1] https://lore.kernel.org/netdev/20250204161015.739430-1-willemdebruijn.kernel@xxxxxxxxx/ [2] https://lore.kernel.org/netdev/20250203150615.96810-1-willemdebruijn.kernel@xxxxxxxxx/ -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
