Gentoo Archives: gentoo-dev

From: Piotr Karbowski <slashbeast@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
Date: Tue, 04 Jan 2022 17:15:58
In Reply to: Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them. by Mike Gilbert
1 Hi,
3 On 04/01/2022 18.03, Mike Gilbert wrote:
4 > On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky <mjo@g.o> wrote:
5 >>
6 >> On Tue, 2022-01-04 at 03:38 +0000, Sam James wrote:
7 >>>
8 >>> ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
9 >>> people may want to turn it off and it makes sense to expose
10 >>> this option for those who do, but we don't need to try support it.
11 >>>
12 >>
13 >> This is another important one. It has security implications, is highly
14 >> confusing, requires kernel support, and is nonstandard as a USE flag
15 >> and as an implementation. Most people should have it off to avoid
16 >> surprises, but disabling it in the kernel can make the userland
17 >> software complain when explicitly built with ACL support.
18 >
19 > I disagree with the claim that "most people" should disable ACL
20 > support at build time. That just gives you partially functional tools.
21 > The ACL behavior can generally be controlled using runtime options.
22 >
23 > Also, you might be able to get away with disabling ACL support on a
24 > server, but desktop users will want ACL support enabled to get
25 > properly functioning udev rules.
26 >
28 I second this.
30 As far as Desktop is concerned acl is basic feature that should be there
31 along with extended attributes, for example, I am pretty sure
32 systemd-login will use acl to grant access to inputs in /dev for the
33 logged user.
35 acl is as much needed as support for multiple users (CONFIG_MULTIUSER),
36 and it also needs support on kernel level, because without this symbol
37 hardly anything will work for you. What I mean here is that argument
38 'needs support in kernel' is not a problem, because everything does need
39 a support in kernel. Try to boot without CONFIG_FUTEX as example, it can
40 be disabled so you could say that it needs support in kernel in a way to
41 constitute that this is something bad and thus should be avoided.
43 -- Piotr.