Re: Possible mistake in commit 3ca459eaba1b ("tun: fix group permission check")
From: Ondrej Mosnacek <omosnace@redhat.com>
Date: 2025-02-04 16:19:14
Also in:
linux-security-module, selinux
On Tue, Feb 4, 2025 at 1:30 AM Paul Moore [off-list ref] wrote:
On Thu, Jan 30, 2025 at 11:48 AM Willem de Bruijn [off-list ref] wrote:quoted
stsp wrote:quoted
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.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@gmail.com/ (local) [2] https://lore.kernel.org/netdev/20250203150615.96810-1-willemdebruijn.kernel@gmail.com/ (local) -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.