19

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.

1
  • 2
    Now I wonder if I should have asked this on unix.stackexchange.com. Trying to pick the right site is always challenging. Jan 23, 2012 at 16:36

2 Answers 2

27

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

2
  • 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. Jan 24, 2012 at 4:27
  • @hopeseekr You can always fork Linux, 100s of GNU utilities, and 1000s of third-party pieces of software so that they don't use S_IRWXG permissions anymore. Call me when you're done.
    – Tobia
    Jul 24, 2017 at 14:12
0

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.

1
  • In case someone ends up reading this, this answer is totally wrong.
    – pgoetz
    Aug 19, 2019 at 13:40

You must log in to answer this question.

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