Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user:nobody:rwx         #effective:--x
group::rw-          #effective:---

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.

share|improve this question
Now I wonder if I should have asked this on unix.stackexchange.com. Trying to pick the right site is always challenging. –  Michael Kropat Jan 23 '12 at 16:36
add comment

2 Answers

up vote 12 down vote accepted

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 Unixes 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 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 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 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 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

share|improve this answer
Awesome, that all makes a lot of sense. Your clarification on the man page confirmed my suspicions about the behavior, while your three explanations were exactly what I needed to become enlightened on the matter. I’m much happier knowing the whys of the design, and I’m so glad you posted your précis, which saved me from doing all that reading to answer the one question. –  Michael Kropat Jan 24 '12 at 4:27
add comment

This behaviour only applies to POSIX ACL entries. The reason this is here is if you have a folder and inside that folder exists a file, you can acl as rwx (for example) the folder and the file. If the group permissions of the file are rw- (which they might be as a typical scenario) the mask thus gives the acl the effective permissions of rw- even though the ACL explicitly denotes rwx.

On the other hand, the directory which nearly always is +x has effective ACL mask permissions also permitting +x.

In summary, this mask is basically used to differentiate permission between files and folders for the POSIX ACL set so that a file does not become executable when it should not normally be.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.