This document about File ACLs makes mention that the masking mechanism was put in place to solve the problem of
... POSIX.1 applications that are unaware of ACLs will not suddenly and unexpectedly start to grant additional permissions once ACLs are supported.
What would be an example of such a situation?
If there was a file with extended ACLs setup according to these intentions by the system admin:
- The file owner should have
- The users in the file's group should have no access (
- Others should have no access (
- An exception to the above three is that the system group
r--permissions on files
I would imagine the corresponding extended ACL for a file would be:
# file: path/to/file # owner: foo # group: bar user::rwx group::--- group:audit:r-- mask::r-- other::---
In this example, if the
mask mechanism was not in place and a tool unaware of extended ACLs attempted to change the group permissions to
--x (it is a strawman argument) the
group:: entry would end up having
group::--x. Why would this "unexpectedly ... grant additional permissions"?
# file: path/to/file # owner: foo # group: bar user::rwx group::--x group:audit:r-- other::---
Based on my understanding, users in the owning group but not in the
audit would gain the ability to execute. Users in the
audit group but not the owning group would not. Users in both groups would gain the ability to execute. I don't understand why the
mask is needed.
If I am misunderstanding something, please explain. It's possible that my strawman does not describe the situation that the quote is talking about. If that is the case, please describe such a situation.