POSIX ACLs — fine-grained permissions beyond owner/group/other · Linux

Standard Linux permissions distinguish only owner, group, and other. That model breaks down when two users need different permissions on the same file, or when a directory needs to give one group read access and another group write access. POSIX ACLs extend the model.

When standard permissions are not enough

Consider these scenarios:

A shared /srv/data directory must be writable by group devs AND readable by group auditors, with nothing for others.
A log file is owned by the application but specific engineers need read access without joining the application’s group.
A build directory needs to be writable by a CI service user and the human engineers who ship to it.

POSIX ACLs handle these cases directly. The standard toolchain is getfacl to read and setfacl to modify.

Anatomy of an ACL

Read-only / Safe— The 'user::rwx' line is the owner ACL (mirrors owner:). 'user:alice:rw-' is a named-user ACL. Two group ACLs (the group: line and group:auditors:r--) grant different access to different groups. The mask line is the effective-rights ceiling for named users and groups, and for the owning group. 'other::---' is unchanged.

$ getfacl /srv/data

getfacl: Removing leading / from absolute path names
# file: srv/data
# owner: root
# group: devs
user::rwx
user:alice:rw-
group::rwx
group:auditors:r--
mask::rwx
other::---

Illustrative output

The ACL entries:

Entry	Meaning
`user::`	Permissions for the file owner
`user:NAME:`	Permissions for a specific named user
`group::`	Permissions for the file group
`group:NAME:`	Permissions for a specific named group
`mask::`	The effective-rights ceiling for all non-owner entries
`other::`	Permissions for everyone else (unchanged from standard mode)

Modifying ACLs with setfacl

Configuration changesetfacl -m— setfacl -m modifies or adds an ACL entry. The format is who:NAME:perms. -x removes an entry. -b removes the entire ACL except the minimum (user::, group::, other::).

$ setfacl -m u:alice:rw /srv/data/project; setfacl -m g:auditors:r /srv/data/project; getfacl /srv/data/project

# file: srv/data/project
# owner: root
# group: devs
user::rwx
user:alice:rw-
group::rwx
group:auditors:r--
mask::rwx
other::---

Illustrative output

Read-only / Safels with ACL— The + at the end of the permission string indicates an extended ACL is present. ls without -l does not show ACLs; use getfacl for full ACL visibility.

$ ls -l /srv/data/project

drwxrwxr-+ 1 root devs 4096 Aug  9 11:11 /srv/data/project

Illustrative output

Default ACLs on directories

A directory can carry a default ACL that propagates to new files and subdirectories created within it:

Configuration changedefault ACL— -d sets a default ACL on a directory. New files and subdirectories created inside inherit these ACL entries as their access ACL. Existing files are unaffected.

$ setfacl -d -m u:alice:rw /srv/data/project; setfacl -d -m g:auditors:r /srv/data/project

...

Illustrative output

Default ACLs are how sysadmins give a whole project tree a consistent permission model without managing every individual file.

How the kernel applies an ACL

When a process tries to open a file, the kernel runs an ACL check in addition to the standard POSIX check:

If the caller is the owner, the user:: entry decides. It grants or denies on its own; the mask does not apply to it.
Else if the caller matches any named user entry, that entry decides, subject to the mask.
Else if the caller’s effective GID or any supplementary group matches the owning group or any named group entry: collect every matching entry — group:: and each matching group:NAME: — apply the mask, and grant if any of them permits the requested access. Otherwise deny.
Else other:: decides.

Step 3 is a union, not a fallback chain. A common and expensive misreading is that the owning group is checked first and named group entries only consulted if it did not match. It is the other way round: all matching group entries are considered together, and one permissive entry is enough. There is no fall-through to other:: once any group entry matched — a user in a matching group that grants nothing is denied, not demoted to other::.

The mask limits every entry except user:: and other:: — including group::. (Restricting it to the named entries is the other common misreading, and it is why a mask tightened by a chmod surprises people.) The mask was added when ACLs were extended from the original draft; it preserves compatibility with applications that read only the standard mode bits and treat the group bit as authoritative.

Verify the reasoning against the normative source rather than the summary: man 5 acl, section ACCESS CHECK ALGORITHM.

Recursive ACL operations

Configuration changesetfacl -R— -R recurses. Combine with -m to set an ACL on every file in the tree. The default walk follows a symlink given as an argument but skips symlinks found inside subdirectories; -L (logical) follows symlinked directories all the way down, and -P (physical) follows none at all. Preview with getfacl -R before you write.

$ setfacl -R -m u:alice:rw /srv/data; getfacl -R /srv/data | head -30

...

Illustrative output

chmod on an ACL-bearing path rewrites the mask

There is no --no-recursive option; setfacl recurses only when you ask it to with -R. Use -P on untrusted trees so a symlinked directory cannot walk the operation somewhere you did not intend, and preview the target set with getfacl -R before writing.

The sharper edge is chmod. On a file that carries an extended ACL, the group-class mode bits map to the mask, not to group:: — so chmod g-w does not just adjust the owning group, it lowers the ceiling for every named user and named group on the file at once. Alice’s rw- becomes an effective r-- without her entry changing, and getfacl still shows user:alice:rw- with a small #effective: comment beside it that is easy to miss.

This is how a routine permission tidy-up silently revokes access that nobody remembers granting. After any chmod on a path with a + in its mode string, re-run getfacl and read the mask line and the #effective: annotations before you call the change done.

Removing ACLs

Configuration changeremove ACLs— -x removes a single named entry. -b removes the entire extended ACL except the minimum (user::, group::, other::). The + at the end of the mode string disappears.

$ setfacl -x u:alice /srv/data; setfacl -x g:auditors /srv/data; setfacl -b /srv/data; ls -l /srv/data

drwxr-x--- 1 root devs 4096 Aug  9 11:11 /srv/data

Illustrative output

Compatibility and tooling notes

Concern	What to know
`cp -p` preserves ACLs; plain `cp` may or may not	`cp --preserve=all` is the safe default for ACL-aware copies
`tar` and ACLs	Modern GNU tar preserves ACLs by default; some backup tools do not
`rsync` and ACLs	`-A` or `--acls` enables preservation; without it, ACLs are lost
ACLs on NFS	NFSv4 supports ACLs natively; NFSv3 does not
ACLs on Samba	Configurable; depends on the `acl_xattr` module
ACLs on backup media	Confirm the backup tool handles them; otherwise restore loses ACLs

When standard permissions are not enough

Anatomy of an ACL

Modifying ACLs with setfacl

Default ACLs on directories

Recursive ACL operations

Removing ACLs

Compatibility and tooling notes

Knowledge check