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