Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

Hi,

On 04/01/2022 18.03, Mike Gilbert wrote:
> On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky <mjo@g.o> wrote:
>>
>> On Tue, 2022-01-04 at 03:38 +0000, Sam James wrote:
>>>
>>> ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
>>> people may want to turn it off and it makes sense to expose
>>> this option for those who do, but we don't need to try support it.
>>>
>>
>> This is another important one. It has security implications, is highly
>> confusing, requires kernel support, and is nonstandard as a USE flag
>> and as an implementation. Most people should have it off to avoid
>> surprises, but disabling it in the kernel can make the userland
>> software complain when explicitly built with ACL support.
>
> I disagree with the claim that "most people" should disable ACL
> support at build time. That just gives you partially functional tools.
> The ACL behavior can generally be controlled using runtime options.
>
> Also, you might be able to get away with disabling ACL support on a
> server, but desktop users will want ACL support enabled to get
> properly functioning udev rules.
>

I second this.

As far as Desktop is concerned acl is basic feature that should be there 
along with extended attributes, for example, I am pretty sure 
systemd-login will use acl to grant access to inputs in /dev for the 
logged user.

acl is as much needed as support for multiple users (CONFIG_MULTIUSER), 
and it also needs support on kernel level, because without this symbol 
hardly anything will work for you. What I mean here is that argument 
'needs support in kernel' is not a problem, because everything does need 
a support in kernel. Try to boot without CONFIG_FUTEX as example, it can 
be disabled so you could say that it needs support in kernel in a way to 
constitute that this is something bad and thus should be avoided.

-- Piotr.