POSIX ACLs Are Only as Clear as the Mask

POSIX ACLs are only as clear as the mask applied to them. Traditional Unix permissions distinguish between the owner, group, and everyone else's access, but POSIX ACLs add named users, groups, and a mask that limits effective permissions. This flexibility is beneficial for service accounts needing access to specific directories without joining broad groups. However, this added layer can create contradictions with the mode bits displayed by the ls command.

The acl(5) manual outlines two types of ACLs: access ACLs that control permissions on individual objects, and default ACLs on directories that determine the ACL inherited by new files and subdirectories. The access check algorithm takes into account the file mode bits, the access ACL, the process's effective user and group identities, and the ACL mask. The mask restricts every named user and group entry, including the owning group entry that corresponds to the file's group permission bits.

A named user may appear to have rwx permissions, but if the mask only grants r-x, the effective permission becomes r-x. The getfacl command can display an effective comment, allowing operators to see the difference between the stored entry and the actual permission applied. This distinction is crucial during incident response. A reviewer might assume a named user can write a file based on the ACL entry, but the mask could limit that authority.

Changing the group bits through a routine chmod command can also alter the mask, silently expanding named-user permissions. To avoid such issues, operators should inspect ACLs before and after mode changes, not just compare the symbolic mode string. Default ACLs on directories influence the permissions inherited by new files and subdirectories, and they override umask settings.

This behavior may surprise applications expecting umask 077 to always produce private files. Before deploying services with shared data directories, operators should create test files and verify their ACLs, including those created by service accounts, archive extraction processes, and administrative tools.

A process with a permissive default ACL can inadvertently create files readable by unintended groups. Default ACLs can be copied by tools that preserve permissions during backups, restores, and deployment scripts, potentially reintroducing stale named-user grants. To conduct a thorough ACL review, operators should examine the owning user and group, mode bits, access ACL, mask, named users and groups, default ACLs on parent directories, the service's effective identity and supplementary groups.

Using getfacl on the actual path and comparing it with namei -l or an equivalent path walk ensures a comprehensive evaluation.

Additionally, operators should test access as the service identity using sudo -u or the platform's equivalent, avoiding tests solely as root. Confirming both permitted and denied operations, along with recording the effective ACL at the time of the test, is essential. ACL changes should be treated as security-relevant configurations, not cosmetic updates, and operators should maintain a set of tested ACL recipes, applying them consistently across environments.

When implementing emergency exceptions, include an owner and expiration date, then verify that removing the named entry does not leave a lingering mask that grants unauthorized access. Ultimately, understanding the entire path and the interplay between ACL entries, mask, mode bits, inheritance, and process identity is crucial for effective access control.