Re: POSIX acls

Hi,

On Tue, 18 Aug 2026 10:46:23 +1200 Duncan McEwan <[email protected]> wrote:
> ...
> The only thing I could think of was that something was taking into account my
> "umask" setting of 027.

Just following up with the results of a some experimentation on the effects of
the umask setting on POSIX ACLs.

% umask
027
% mkdir test
% setfacl -d -m u::rwx,g::rwx,o::,m::rwx test
% getfacl -d test
# file: test
# owner: duncan
# group: ecs
user::rwx
group::rwx
mask::rwx
other::---
% mkdir test/sub1
% touch test/file1
% ls -l test
total 6
-rw-r-----+ 1 duncan  ecs    0 Aug 19 10:52 file1
drwxr-x---+ 2 duncan  ecs  512 Aug 19 10:52 sub1
% getfacl test/file1
# file: test/file1
# owner: duncan
# group: ecs
user::rw-
group::rwx              # effective: r--
mask::r--
other::---
% getfacl test/sub1
# file: test/sub1
# owner: duncan
# group: ecs
user::rwx
group::rwx              # effective: r-x
mask::r-x
other::---

> I also noted that my hoped for behaviour *did* occur on an ArchLinux system
> even with a 027 umask.

As far as I can see the NetBSD 10.x behaviour makes ACLs not useful for the main
thing I want them for :-(  That is, to ensure that any files or sub-directories
created under a top level directory are always accessible to members of the
group owner for that directory, regardless of the umask setting of the creator
and without them having to remember to chmod any files or directories.

For completeness here is a repeat of the above with umask set to 0.

% umask 0
% mkdir test/sub2 
% touch test/file2
% ls -l test
total 12
-rw-r-----+ 1 duncan  ecs    0 Aug 19 10:52 file1
-rw-rw----+ 1 duncan  ecs    0 Aug 19 10:53 file2
drwxr-x---+ 2 duncan  ecs  512 Aug 19 10:52 sub1
drwxrwx---+ 2 duncan  ecs  512 Aug 19 10:53 sub2
% getfacl test/file2
# file: test/file2
# owner: duncan
# group: ecs
user::rw-
group::rwx              # effective: rw-
mask::rw-
other::---
% getfacl test/sub2
# file: test/sub2
# owner: duncan
# group: ecs
user::rwx
group::rwx
mask::rwx
other::---
% getfacl test/file1
# file: test/file1
# owner: duncan
# group: ecs
user::rw-
group::rwx              # effective: r--
mask::r--
other::---
% getfacl test/sub1
# file: test/sub1
# owner: duncan
# group: ecs
user::rwx
group::rwx              # effective: r-x
mask::r-x
other::---
%

Note that after changing my umask to 0 the ACL mask for sub1 and file1 is still
"r-x" and "r--" respectively, suggesting that the umask setting at the time the
ACL was created was taken into account in determining the ACL mask setting.

The default ACL for test *is* having an effect though.  Without it, with a umask
of 0 the mkdir would create a directory with mode 0777 and touch would create a
file with mode 0666.  But in both cases permission for 'others' is as per the
default ACL - ie: no access.

When I asked Gemini whether umask should have any effect on determining the
POSIX ACL mask setting it told me it doesn't if there is a default ACL on the
parent directory.  Whether or not this is AI hallucination though I'm not sure.
Is it actually optional behaviour and Linux chose a different option?

Lastly, if I replace the "incorrect"(?) mask on test/sub1 and test/file1 I get
the expected permissions.

% setfacl -m m::rwx test/file1 test/sub1
% ls -l test 
total 12
-rw-rwx---+ 1 duncan  ecs    0 Aug 19 11:05 file1
-rw-rw----+ 1 duncan  ecs    0 Aug 19 10:53 file2
drwxrwx---+ 2 duncan  ecs  512 Aug 19 11:05 sub1
drwxrwx---+ 2 duncan  ecs  512 Aug 19 10:53 sub2

Duncan