Why would you expect that?
From the man setfacl
man page:
The setfacl utility recognizes the following ACL entry formats (blanks inserted for clarity):
[d[efault]:] [u[ser]:]uid [:perms]
Permissions of a named user. Permissions of the file owner if uid is empty.
[d[efault]:] g[roup]:gid [:perms]
Permissions of a named group. Permissions of the owning group if gid is empty.
[d[efault]:] m[ask][:] [:perms]
Effective rights mask
[d[efault]:] o[ther][:] [:perms]
Permissions of others.
ACLs are separate from the traditional Unix access controls -- owner, group, and the rights mask for owner, group, and others.
While we cannot think of any reason why you'd need an ACL with the same user or group as the traditional access controls, it is not in the Unix philosophy to decide that it should be therefore forbidden. setfacl
happily allows you to do that; KISS is good.
If you don't like that behaviour, and would prefer the utility to "autodetect" that situation, you can write your own wrapper around setfacl
. In a shell script, you can use stat -c %U FILE
to obtain the name of the owner, and stat -c %G FILE
the name of the group of file or directory FILE
. In organizations with complex sets of users and groups such wrappers -- not just for setfacl
, but for all file ownership management -- are ubiquitous in my experience.