touch/mkdir seems to ignore default ACL

Question

I am pretty sure it is a stupid mistake but I can't seem to figure it out by myself, so please have a look.

I set up an ACL for the current folder like so:

zigbee2mqtt@nuc:/tmp/folder$ getfacl .
# file: .
# owner: zigbee2mqtt
# group: zigbee2mqtt
user::rwx
user:stack:r-x
user:zigbee2mqtt:rwx
user:milkpirate:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:stack:r-x
default:user:zigbee2mqtt:rwx
default:user:milkpirate:rwx
default:group::---
default:mask::rwx
default:other::---
zigbee2mqtt@nuc:/tmp/folder$ id
uid=978(zigbee2mqtt) gid=977(zigbee2mqtt) groups=977(zigbee2mqtt)

so when I now create a folder/file in that folder like so:

zigbee2mqtt@nuc:/tmp/folder$ touch foo; mkdir bar

It results in the following permission on the folder foo:

zigbee2mqtt@nuc:/tmp/folder$ getfacl foo
# file: foo
# owner: zigbee2mqtt
# group: zigbee2mqtt
user::rwx
user:stack:r-x
user:zigbee2mqtt:rwx
user:milkpirate:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:stack:r-x
default:user:zigbee2mqtt:rwx
default:user:milkpirate:rwx
default:group::---
default:mask::rwx
default:other::---

which looks fine so far.

But the ACL of the file then looks off:

# file: bar
# owner: zigbee2mqtt
# group: zigbee2mqtt
user::rw-
user:stack:r-x                  #effective:r--
user:zigbee2mqtt:rwx            #effective:rw-
user:milkpirate:rwx             #effective:rw-
group::---
mask::rw-
other::---

1. I would expect the mask to be rwx (desired).
2. Since group and other are --- (desired) the permission in ls -la to be the same, but they are:

zigbee2mqtt@nuc:/tmp/folder$ ls -la
total 20
drwxrwx---+  3 zigbee2mqtt zigbee2mqtt 4096 Jan 15 17:55 .
drwxrwxrwt  16 root        root        4096 Jan 15 17:59 ..
-rw-rw----+  1 zigbee2mqtt zigbee2mqtt    0 Jan 15 17:55 bar
drwxrwx---+  2 zigbee2mqtt zigbee2mqtt 4096 Jan 15 17:55 foo

but I would expect (and desire):

zigbee2mqtt@nuc:/tmp/folder$ ls -la
total 20
drwxrwx---+  3 zigbee2mqtt zigbee2mqtt 4096 Jan 15 17:55 .
drwxrwxrwt  16 root        root        4096 Jan 15 17:59 ..
-rw-------+  1 zigbee2mqtt zigbee2mqtt    0 Jan 15 17:55 bar
drwx------+  2 zigbee2mqtt zigbee2mqtt 4096 Jan 15 17:55 foo

EDIT: Ok, did some testing and all seems to work as desired, the result of ls -la does not seem to reflect the correct rights:

zigbee2mqtt@nuc:/tmp/folder$ sudo -u nginx -g zigbee2mqtt bash
nginx@nuc:/tmp/folder$ ls
ls: cannot open directory '.': Permission denied

Answer 1

What you see in the ls listing are the "traditional" permission bits, all you'd have in a system that doesn't support ACLs, and all that can be used by tools (or users!) that aren't ACL-aware.

The "traditional" group permission bits don't correspond to the owning group ACL, but to the ACL mask (acl(5) man page):

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 entry.

What the mask does, is limit the permissions that can be granted by ACL entries for named users, named groups, or the owning group. In a way, you can think of the three sets of "traditional" permission bits as applying to 1) the owning user, 2) other explicitly defined users (without ACLs: members of a the owning group; with ACLs: those plus other named users or members of other named groups), and 3) everyone else.

The practical reasoning there is that if a user or program wants to make sure only the owner has write permissions to the file, something like chmod go-w still works to do that, even without the actor knowing about ACLs.

So, having it show rwx for the group in the ls listing is by design, since you have the user:zigbee2mqtt:rwx and user:stack:r-x ACL entries there. The ls output just hints that there are some others apart from the owning user who have read, write and/or execute permissions on the file. Setting the mask to 000 (with e.g. chmod g-rwx or the appropriate setfacl command) would make those ACL entries for user:zigbee2mqtt and user:stack ineffective.

---

When you create a file with touch, and see mask::rw- on it, that's because touch and most other tools create regular files with permissions 0666, not 0777, leaving the x bits off. Most files shouldn't be executable. Regardless of the ACLs, the permissions passed to the open() system call still count, the same as if the permissions were changed with chmod(). Apart from leaving the x bits off, this allows a program to create private files by setting the permissions bits to 0600.