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 rwx permissonsThe 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 audit has r-- permissions on filesI would imagine the corresponding extended ACL for a file would be:# file: path/to/file# owner: foo# group: baruser::rwxgroup::---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: baruser::rwxgroup::--xgroup: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.
Example of situation where ACL unaware tools would grant unintended permssions
permissions;filesystems;acl