Jan 23, 2012
tom

Why does chmod(1) on the group affect the ACL mask?

Question

I am trying to understand this Unix behavior (which I happen to be testing on Ubuntu 11.10):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Notice that the chmod(1) command has updated the ACL mask. Why does this happen?

The SunOS manpage has the following to say:

If you use the chmod(1) command to change the file group owner
permissions on a file with ACL entries, both the file group owner
permissions and the ACL mask are changed to the new permissions. Be
aware that the new ACL mask permissions may change the effective
permissions for additional users and groups who have ACL entries on
the file.

I ask because it would be convenient for me if chmod(1) did not have this behavior. I hope that by understanding why it does what it does, I can better design how I set up filesystem permissions.

Answer

It would not be convenient for you if chmod() didn’t have this behaviour.

It would be highly inconvenient, because things that people traditionally expect to work on Unices would break. This behaviour serves you well, did you but know it.

It’s a shame that IEEE 1003.1e never became a standard and was withdrawn in 1998. In practice, fourteen years on, it’s a standard that a wide range of operating systems — from Linux through FreeBSD to Solaris — actually implement.

IEEE 1003.1e working draft #17 makes for interesting reading, and I recommend it. In appendix B § 23.3 the working group provides a detailed, eight page, rationale for the somewhat complex way that POSIX ACLs work with respect to the old S_IRWXG group permission flags. (It’s worth noting that the TRUSIX people provided much the same analysis ten years earlier.) I’m not going to copy it all here. Read the rationale in the draft standard for details. Here is a very brief précis:

  • The SunOS manual is wrong. It should read

    If you use the chmod(1) command to change the file group owner permissions on a file with ACL entries, either the file group owner permissions or the ACL mask are changed to the new permissions.

    This is the behaviour that you can see happening, despite what the current manual page says, in your question. It’s also the behaviour specified by the draft POSIX standard. If a CLASS_OBJ (Sun’s and TRUSIX’s terminology for ACL_MASK) access-control entry exists, the group bits of a chmod() set it, otherwise they set the GROUP_OBJ access-control entry.

  • If this 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 Unices, 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 CLASS_OBJ. Without this, setting the old file permissions to 000 wouldn’t affect any USER or GROUP entries and other users 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 Unices 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 twelve years later. And again, this doesn’t work unless the old S_IRWXG maps to CLASS_OBJ if it exists, because otherwise that chmod command wouldn’t turn off any USER or GROUP access control entries, leading to users other than the owner and non-owning groups 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

Answered by JdeBP

Related posts:

  1. Chmod: defintion of everyone (777)
  2. what chmod and owner:group settings are best for a web application?
  3. Finding all files in NTFS with specific user or group in ACL
  4. chmod: copy permissions (with extended permissions) from one file to another
  5. chmod apply to user group

Leave a comment