At the beginning, I have these permissions for a file:

# file: jar
# owner: my_user
# group: my_user

After running this:

setfacl -m u:my_user:--- jar

and get this permissións:

# file: foobar
# owner: my_user
# group: my_user

I expected my_user not to have permissión to read (for example) this file, but it has..


Try the next command:

setfacl -m u::--- jar

With that commando you apply to the owner.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.