Default ACL application on new file

[ravenor]

Hi all,

I've been looking for information about this particular behaviour when creating a new file in a folder with default ACL:s.

Why does the user:: get rw- but the group:: get rwx permissions on the file ACL when the default ACL in the directory is set to rwx for both? The group:: gets the effective permission rw- through the mask, why?

I've come to understand there is some peculiar relation between the group permission the group:: ACL entry and the mask ACL entry. The mask is apparently recalculated if you add an ACL entry and that might inadvertantly change the group permission.



umask: 0027

folder getfacl output
# file: folder1/
# owner: user1
# group: group1
# flags: -s-
user::rwx
group::rwx
group:group2:r-x
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:group2:r-x
default:mask::rwx
defaultther::---

When I create a new file in this folder the file gets these ACL:s

# file: test.txt
# owner: user1
# group: group1
user::rw-
group::rwx #effective:rw-
group:group2:r-x #effective:r--
mask::rw-
other::---

 

[ravenor]

Mein gott.

acl: Access Control Lists - Linux Man Pages (5) (systutorials.com)

Let me see if I understand this correctly.

Permissions for the "group::rwx #effective:rw-" entry on the file shows the correct permissions on the ACL_GROUP_OBJ. But since there also is an ACL_GROUP or ACL_USER entry on the file there is a ACL_MASK entry. When there is an ACL_MASK entry the "group permission bits" does not correspond to the ACL_GROUP_OBJ any longer, they corresponds to the ACL_MASK, hence the #effective: rw- result.

Both the ACL_USER_OBJ and ACL_MASK is created with the default 666 base file permissions applied with the directory's default ACL mask (not the systemwide umask 027, if so the ACL_MASK should be r--).

The ACL_MASK entry is calculated from the maximum access rights that can be granted by ACL_USER, ACL_GROUP_OBJ and ACL_GROUP (though apparently not on file creation since the group2:r-x permissions is not reflected in the mask).

Wow, this seems quite a chore to keep track of. Maybe it's best practice to set the file group to some dummy group since the file group permissions might change if you add or remove ACL:s?

I'd appreciate if anyone wants to shed some light on my findings if they are correct or not?

br,

ravenor

 

[f33dm3bits]

You noticed that correctly and never thought about the reason behind it or why but the best explanation I could find was in the ACL man page, which is also mentioned on the page that you linked in your last reply.

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 per‐
missions 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 per‐
missions of the ACL_OTHER_OBJ entry.

The file owner, group, and other permissions always match the permissions of the corresponding ACL entry. Modifica‐
tion of the file permission bits results in the modification of the associated ACL entries, and modification of these
ACL entries results in the modification of the file permission bits.

All I can say is that ACL's aren't hard, in your average situation you only use a couple when you do use them and I've always had them working the way I want without running into problems so I wouldn't over think this if I were you.

 

[ravenor]

Thanks for the read through. It's a bit too complicated. You sort of have to try it out and hope for the best.