Hi,
On 04/01/2022 18.35, Michael Orlitzky wrote:
On Tue, 2022-01-04 at 12:03 -0500, Mike Gilbert wrote:
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.
I understand why people would disagree in this case, but isn't that a
an argument for having the flag?
There are plenty of great uses for ACLs, but unless you're extremely
knowledgeable, they also add a million new ways to compromise your
system. For example, if you untar a file with a default-ACL'd directory
in it and don't notice the little plus sign, you might wind up
unknowingly creating world-writable files. Even if you do notice the
ACL, you have to be an expert in the interaction between umask,
permission bits, the ACL mask, effective permissions, conflicting ACLs,
and all of the tools you're using to understand what will actually
happen or how to properly fix it. It's not something normal people can
handle.
And none of which happens unless you intentionally trigger it.
1. To have ACL break things on new (extracted) files you'd first need to
have default ACL set on parent directory where you extract to --
otherwise they won't be carried and no problem
2. unless you add --acl to both create and extract, no acl will be added
to tarball and/or extracted onto system
Running 'tar --acl ...' or 'setfacl -d ...' does not happen by accident
and argument that you should disable acl to not run into issues with
above does not make much sense.
Sure, acl and how chmod manipulate mask on ACL-enabled entities is not
very simple, but nothing will break by itself just because you have acl
support enabled, you would need to try very hard to run into problems.
-- Piotr.
