Csdrhrt

I'm trying to figure out why the output of ls command has changed. I mean group permissions for a file.

I've created a file named "file" and changed its owner&group:

[root@training group3]# touch file

[root@training group3]# ls -la file

-rw-r--r--. 1 root root 0 Sep  8 15:29 file

[root@training group3]# chown uczen file

[root@training group3]# chgrp group3 file

[root@training group3]# ls -la file

-rw-r--r--. 1 uczen group3 0 Sep  8 15:29 file

[root@training group3]# getfacl file

# file: file

# owner: uczen

# group: group3

user::rw-

group::r--

other::r--

Then I've added additional rwx rights for the user "ula":

[root@training group3]# setfacl -m u:ula:rwx file

[root@training group3]# getfacl file

# file: file

# owner: uczen

# group: group3 

user::rw- 

user:ula:rwx 

group::r-- 

mask::rwx 

other::r--

My question is why the output of ls -la command (below) shows now "rwx" for the group compared to "r--" shown by getfacl above. Why the perms for the group have been (seemingly?) changed if by setfacl I've only added rights for some user (ula)

[root@training group3]# ls -la file

-rw-rwxr--+ 1 uczen group3 0 Sep  8 15:29 file

I don't remember where I found the rationale explained, but it's basically to avoid surprises.

Most people are used to the three sets visible in ls describing all access that anyone may obtain. So if the "group" column retained its original meaning, it might create accidental security holes. For example, you have this file...

-rw-rwxr--+ 1 uczen group3 0 Sep  8 15:29 file

...and you want to restrict anyone but the owner from writing it, so you run chmod go-w, and end up with this:

-rw-r-xr--+ 1 uczen group3 0 Sep  8 15:29 file

Now, if you're in a hurry, you might not notice the + sign of ACLs being present, or not know about its meaning. If there is an ACL allowing someone else to write to that file, you end up with the permissions being more open than expected.

Note that this applies to programs as well, not just humans. Some programs – for example, ssh – check the Unix permission bits and require group/other to have no permissions at all. If the file had a permissive ACL, ssh wouldn't know it. (Even if someone updated OpenSSH to know about ACLs, older versions would still not know about them.)

Because of this, POSIX ACLs have a special mask: entry to set the maximum of all permissions granted to the default group and to all ACL members, and the "group" field of Unix permissions is changed to display the value of mask: instead of the Unix group. For example, if you do chmod g=rx, you will actually set mask::rx.

So if you see rw-r--r--+ there, you can be sure that nobody can write that file, regardless of what ACLs may be present, and without actually having to check them. Similarly, if a program sees a file having permissions 0600, it also can be sure of that without needing special knowledge about POSIX ACLs (and in the future RichACLs, NFSv4 ACLs, or other types – if they follow this special behavior).

Notice that the getfacl output still lists the default group entry as group::r--. If you want to actually change that specific entry, you will need to do it using setfacl.

See also:

• Andreas Grünbacher, SuSE Labs, POSIX Access Control Lists on Linux
  

The link in the above post is dead, and this one has a different answer: https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html

Accordingly, the acl mask is shown in the group permissions field, instead of the group permissions being shown.

Here is a better explanation: https://unix.stackexchange.com/questions/65888/setfacl-incorrectly-changes-group-permissions/498907#498907