3

It might be the time of night, but this is puzzling me. Picture the following.

[root@node1 acltest]# getfacl foo/
# file: foo
# owner: root
# group: testuser
user::rwx
group::r-x
other::---

[root@node1 acltest]# ls -la .
total 24
drwxr-xr-x  3 root root     4096 Feb  9 21:53 .
drwxr-xr-x 25 root root     4096 Feb  9 21:54 ..
drwxr-x---  2 root testuser 4096 Feb  9 21:53 foo
[root@node1 acltest]# setfacl -m m::rwx foo
[root@node1 acltest]# getfacl foo/
# file: foo
# owner: root
# group: testuser
user::rwx
group::r-x
mask::rwx
other::---

[root@node1 acltest]# ls -la .
total 24
drwxr-xr-x   3 root root     4096 Feb  9 21:53 .
drwxr-xr-x  25 root root     4096 Feb  9 21:54 ..
drwxrwx---+  2 root testuser 4096 Feb  9 21:53 foo
[root@node1 acltest]# su - testuser
[testuser@node1 ~]$ cd /acltest/foo/
[testuser@node1 foo]$ ls -la .
total 16
drwxrwx---+ 2 root testuser 4096 Feb  9 21:53 .
drwxr-xr-x  3 root root     4096 Feb  9 21:53 ..
[testuser@node1 foo]$ touch bar
touch: cannot touch `bar': Permission denied

In words: I create a directory foo, with mode 0750, root as owner and testuser as the group. (testuser is the private group of testuser, but that doesn't matter.)

The getfacl command correctly shows no ACL's on this directory and there is not mask yet. The mask will be set accordingly to the group permissions if I would add a named group or user now.

If I explicitly set the mask to rwx now, the group permissions as shown by ls change too. I know it happens the other way around (the mask changes when the group permissions change), but this seems puzzling.

The more puzzling because the getfacl output does not show the group permissions as rwx but - as said - ls does.

Which one is right? Apparently, the output of getfacl is right, because testuser cannot write to foo. As expected, by the way, because I did not grant the testuser group any permissions to do so.

It goes on. I cannot allow the testuser group write permissions on foo by just using chmod. I have to explicitly set an ACL using setfacl -m g:testuser:rwx foo to allow testuser to finally touch foo/bar.

Can someone explain the rationale behind the difference in the outputs of getfacl and ls? I know it can be tricky to have normal permissions go together with ACL's, but this seems plain wrong. (Though I expect to be missing something glaringly obvious ;))

I have already seen Why does chmod(1) on the group affect the ACL mask?

Community
  • 1
wzzrd
  • 10,269
  • 2
  • 32
  • 47
  • I just verified that this behaviour happens on FreeBSD9, Debian, RHEL5 and RHEL6. So it's either a bug that has spread itself very broadly, or it's not a bug at all. In that case, someone explain this to me :) – wzzrd Feb 10 '12 at 14:22

2 Answers2

4

From the man(5) page of acl

    ACL_MASK        The ACL_MASK entry denotes the maximum access
                       rights that can be granted by entries of type
                       ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP.

and later:

  1. else if the effective group ID or any of the supplementary group IDs of the process match the file group or the qualifier of any entry of type ACL_GROUP, then
          if the ACL contains an ACL_MASK entry, then

              if  the ACL_MASK entry and any of the matching ACL_GROUP_OBJ
              or ACL_GROUP  entries  contain  the  requested  permissions,
              access is granted,

              else access is denied.

This means that rwx CAN be granted on the dir, but the chmod bits have to agree with it.

AndreasM
  • 1,083
  • 8
  • 13
  • Yeah, close. This states that the mask and the group have to agree on giving write access, which is logical. But it does not explain why 'ls' shows a file as writable by a group when it clearly is not. – wzzrd Feb 10 '12 at 14:21
  • 2
    Yes, sorry. Here again from the acl(5): `If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry.` I think that should answer the question. – AndreasM Feb 10 '12 at 15:14
  • Well, how about that. I completely missed that :) Thanks for taking the time to read that manpage more thoroughly than I did ;) – wzzrd Feb 10 '12 at 15:28
0

I would like to add that when ACLs are used on an object, the permissions listed by ls -l is bit different.

Accoring to man ACL(5):

CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS

The permissions defined by ACLs are a superset of the permissions specified by the file permission bits.

There is a correspondence between the file owner, group, and other permissions and specific ACL entries: the owner permissions correspond to the permissions of the ACL_USER_OBJ entry. If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. Otherwise, if the ACL has no ACL_MASK entry, the group permissions correspond to the permissions of the ACL_GROUP_OBJ entry. The other permissions correspond to the permissions of the ACL_OTHER_OBJ entry.

So when using ACLs you should consider the group permission section of ls -l output as the ACL mask .

ob_dev
  • 93
  • 1
  • 9