POSIX Default ACLs Inherit by Rule, Not by Intent
A shared directory can look correctly restricted while files created inside it inherit access that no one consciously granted. POSIX access control lists explain this gap. The access ACL controls an existing object. A directory can also carry a default ACL, and that second ACL determines the initial access ACL of objects created within the directory.
The inheritance rule is explicit
The Linux acl(5) manual says a new file, directory, FIFO, socket, or device node starts with the containing directory's default ACL when one is present. The mode requested at creation then restricts the inherited entries. Existing objects are not retroactively changed by adding a default ACL to their parent.
This distinction matters in application directories, upload trees, build caches, and group workspaces. A team may add a named group to the parent directory and test access with its existing files. The next application write creates a new object with an access ACL derived from the default ACL. If the default entries were broader than intended, the new object is broader too.
The mask still limits named entries
An extended ACL contains a mask entry. The mask caps permissions granted to named users, the owning group entry, and named groups. A getfacl display can therefore show a named group with write permission while the effective column reflects a more restrictive mask.
Do not read the permission field alone. Compare the entry with the mask and inspect the effective permissions for the user or group that actually runs the workload. Also check whether a later chmod changed the ACL mask, because the mode bits and ACL entries are linked.
Test creation, not only access
Start with a parent directory and a fresh file:
getfacl -p /srv/shared
setfacl -d -m g:analysts:rw- /srv/shared
umask 027
touch /srv/shared/acl-test
getfacl -p /srv/shared/acl-test
The test must use the same user, group, umask, and creation path as the production workload. A shell test may not reproduce files written by a daemon with a different identity or service manager settings. Remove the test object afterward through the normal change process.
Record the parent's access ACL, its default ACL, and the resulting ACL on several new objects. Include files and directories because a new directory can carry a default ACL of its own. If the inherited result is wrong, correct the parent's default entries and the mask before creating more content.
Keep the policy understandable
Name groups by a stable responsibility, not by a temporary project. Avoid stacking overlapping individual entries when a group entry expresses the same access. Review who may change the parent's ACL, because that control includes the power to change inheritance for future objects.
When the directory is intended to return to mode-bit behavior, setfacl -k removes the default ACL. Treat that as a security change, not cleanup. Verify the new creation result and document why existing objects were or were not updated.
Default ACLs are useful because they make inheritance predictable. They become dangerous when operators expect inheritance to follow intent and the configured entries and mask decide it.
Top comments (0)