Hi,
On 04/01/2022 18.03, Mike Gilbert wrote:
On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky <m...@gentoo.org> 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.
