2

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:

  1. The file owner should have rwx permissons
  2. The users in the file's group should have no access (---)
  3. Others should have no access (---)
  4. An exception to the above three is that the system group audit has 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.

Improve this question

1 Answer 1

Reset to default
3

If the mask and its link to the S_IRWXG bits weren't the case, applications that did various standard things with chmod(), expecting it to work as chmod() has traditionally worked on old non-ACL Unixes, would either leave gaping security holes or see what they think to be gaping security holes:

  • Traditional Unix applications expect to be able to deny all access to a file, named pipe, device, or directory with chmod(…,000). In the presence of ACLs, this only turns off all user and group permissions if the old S_IRWXG maps to the mask. Without this, setting the old file permissions to 000 wouldn't affect any ACL entries for specific users/groups and other users/groups would, surprisingly, still have access to the object.

    Temporarily changing a file's permission bits to no access with chmod 000 and then changing them back again was an old file locking mechanism, used before Unixes gained advisory locking mechanisms, that — as you can see — people still use today.

  • Traditional Unix scripts expect to be able to run chmod go-rwx and end up with only the object's owner able to access the object. Again — as you can see — this is still the received wisdom even now, decades after the invention of Unix ACLs. And again, this doesn't work unless the old S_IRWXG maps to the mask, because otherwise that chmod command wouldn't turn off any ACL entries for specific users/groups, leading to users/groups other than the owner retaining access to something that is expected to be accessible only to the owner.
  • A system where the permission bits were otherwise separate from and anded with the ACLs would require file permission flags to be rwxrwxrwx in most cases, which would confuse the heck out of the many Unix applications that complain when they see what they think to be world-writable stuff.

    A system where the permission bits were otherwise separate from and ored with the ACLs would have the chmod(…,000) problem mentioned before.

Further reading

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .