4

I have run the following script to set permissions into /etc/nginx

#!/usr/bin/env bash


sudo chown -R root:root /etc/nginx
sudo chmod -R 0750 /etc/nginx
sudo setfacl -Rbk -m g:baa:rwx /etc/nginx
sudo setfacl -R --mask -m g:www-data:rx /etc/nginx

However, when I check the permissions afterwards there is a discrepancy in the results for the 'group' of ls -al and getfacl

$ ls -al /etc/nginx
total 24
drwxrwx---+   5 root root 4096 Mar 18 17:07 .

$ getfacl /etc/nginx
getfacl: Removing leading '/' from absolute path names
# file: etc/nginx
# owner: root
# group: root
user::rwx
group::r-x
group:www-data:r-x
group:baa:rwx
mask::rwx
other::---

Why?

Baa
  • 3,770
  • 1
  • 31
  • 46
  • Because ls -l doesn't show access control list attributes. It merely shows their pure existance by means of the + sign. That is: whenever you see a + in the permissions, issue getfacl afterwards. – PerlDuck Mar 18 '18 at 17:26
  • 2
    Doesn't getfacl list the POSIX permissions too though? Isn't that what group::r-x is in the output? – Baa Mar 18 '18 at 17:33

1 Answers1

3

What you see with ls is the mask entry of the ACL. From man setfacl, the mask entry seems to reflect the maximum possible permissions that can be set on an ACL entry.

the permissions of the mask entry are further adjusted to include the union of all permissions affected by the mask entry

The access rights you see in your example with ls for the default group root:rwx are wrong as the effective rights are now controlled by the ACLs.

Thomas
  • 6,463
  • 13
  • 34
  • 38
  • Crazy stuff, I guess it's meant to do that? – Baa Mar 18 '18 at 22:20
  • 1
    Yes, it is meant to do that. I just found the description in "CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS" in man acl (same as on https://www.commandlinux.com/man-page/man5/acl.5.html) But I was irritated as well. – simohe Oct 09 '20 at 13:15