POSIX ACLs Are Only as Clear as the Mask

Traditional Unix permissions answer a simple question: what can the owner, group, and everyone else do? POSIX access control lists add named users and groups, plus a mask that limits effective permissions. The extra flexibility is useful when a service account needs access to one directory without joining a broad group. It also creates another layer that can contradict the mode bits shown by ls.

The acl(5) manual describes two ACL types. An access ACL controls permissions on an object. A default ACL on a directory determines the ACL inherited by newly created files and subdirectories. The access check algorithm considers the file mode bits, the access ACL, the process's effective user and group identities, and the ACL mask.

The mask is not decoration

Every named user and named group entry is limited by the ACL mask. The owning group entry also corresponds to the file's group permission bits. A named user may appear to have rwx, but if the mask grants only r-x, the effective permission is r-x. The getfacl output can show an effective: comment so an operator can see the difference between the stored entry and the permission that is actually applied.

This matters during incident response. A reviewer may see a named user entry and conclude that the account can write a file. The mask may reduce that authority. Conversely, a routine chmod that changes the group bits can change the mask and silently widen named-user permissions. The safer workflow is to inspect the ACL before and after a mode change, not compare only the symbolic mode string.

Default ACLs change creation behavior

A directory with a default ACL supplies ACL entries to new files and subdirectories. The inheritance rules are not identical to umask. The manual notes that when a default ACL applies, the umask is ignored and the default ACL determines the inherited permissions. This can surprise an application that assumes umask 077 will always produce private files.

Before deploying a service with a shared data directory, create test files and inspect their resulting ACLs. Check files created by the service account, by an archive extraction process, and by an administrative tool. A process with a permissive default ACL can create a file that is readable by a group the application did not intend to expose.

Default ACLs can be copied by tools that preserve permissions. Backups, restore jobs, and deployment scripts should preserve the ACL intentionally rather than silently dropping it. The getfacl and setfacl manual pages include recursive backup and restore workflows; those workflows need their own review because a restore can reintroduce a stale named-user grant.

Audit the effective path

A practical ACL review examines:

  • the owning user and group;
  • the mode bits and access ACL;
  • the mask;
  • named users and groups;
  • default ACLs on parent directories;
  • the service's effective identity and supplementary groups.

Use getfacl on the actual path and compare it with namei -l or an equivalent path walk. A file may have a safe ACL while a parent directory grants traversal to a broader group. The check should also include the mount options and any overlay or container layer that changes the view of the filesystem.

Test access as the service identity with sudo -u or the platform's equivalent. Do not test only as root, because root may bypass checks that apply to the service. Confirm both a permitted operation and a denied operation, and record the effective ACL at the time of the test.

Avoid accidental normalization

Some deployment tools rewrite permissions on every run. A configuration management task that calls chmod can recalculate the ACL mask; an archive extraction can replace a file and inherit a different default ACL. Treat ACL changes as security-relevant configuration, not cosmetic cleanup.

Keep a small set of tested ACL recipes and apply them through the same path in every environment. When an emergency exception is added, include an owner and an expiration date. Then verify that removing the named entry does not leave a stale mask that continues to grant access through the owning group.

The takeaway

POSIX ACLs are a useful tool for precise file access, but their effective permissions are the result of entries, mask, mode bits, inheritance, and process identity. Review the whole path. A grant that looks narrow in one line of getfacl may be wider than intended when the mask and parent defaults are included.

References