You set the access-control conventions for a fleet of Linux servers. When do you accept POSIX ACLs on shared directories, and when do you insist the access be expressed as group membership instead?
answer
- stored with the identity or with the object
- one lookup versus walking every filesystem
- exceptions per path, roles per person
- invisible to any central directory
- chmod is the silent enemy
basics
~20 sUse group membership as the default, because it is managed centrally and audited in one place; use ACLs for genuine per-path exceptions that would otherwise force a single-purpose group. Any ACL you accept should be declared in configuration management, not applied by hand.
solid answer
~50 sGroups scale with *people*: membership lives in one directory service, changes propagate everywhere at once, and answering "what can this account reach" needs one lookup. ACLs scale with *paths*: the state sits on each filesystem, is invisible in `ls -l` beyond a `+`, can only be enumerated by walking trees with `getfacl -R`, and is lost by any copy or restore that does not carry extended attributes. So the default is groups. ACLs earn their place where the exception really is per-path — one service account writing into one drop directory, an auditor granted read on one tree, a case where a group would exist for exactly one directory. The conditions I attach: the ACL is declared in configuration management alongside the directory, a default ACL is set so new files inherit rather than depending on each writer's umask, and no blanket recursive `chmod` runs over that tree, because on ACL-bearing files chmod rewrites the mask and silently voids every named entry.
go deeper
Understand the basic tradeoff: group membership is managed in one place for a person, while an ACL is set on one directory and only visible there.
Be able to say why ACLs are harder to operate — no central inventory, easily clamped by a later chmod, lost by copies that skip extended attributes — and give a concrete case where an ACL is still the right call.
Bring the failure modes with mechanisms attached: chmod rewriting the mask, restores dropping extended attributes, and drift with no reconciliation, plus the controls you attach when you do approve one.
Own the policy: state the default, the ratio that decides exceptions, the conditions you attach (declared in configuration management, default ACL for inheritance, excluded from blanket chmod, periodically audited), and which access requests you refuse on design grounds rather than solving with permissions at all.
## Two primitives that scale along different axes Both mechanisms express "this principal may do this thing here", but they store the relationship in different places, and that is the whole decision. **Group membership** is stored with the *identity*. It lives in `/etc/group` or, at fleet scale, in a directory service, and the filesystem only records a GID. Add a person to a group and every file on every host owned by that group is affected instantly. Ask "what does this account have access to" and you enumerate their groups from one source. **An ACL entry** is stored with the *object*. It sits on one inode on one filesystem on one host. There is no index — the only way to answer "where do we grant this user special access" is to walk every filesystem with `getfacl -R` or `find`. Nothing in a directory service knows the entry exists. That asymmetry produces the default: express access as membership wherever the access is really about a role, and reach for ACLs when it is really about a path. ## The operational costs of ACLs, stated honestly A senior answer names these rather than gesturing at "they're harder": 1. **Discoverability.** A `+` in `ls -l` is the only signal, and it appears only if someone runs `ls -l` on that directory. No dashboard shows the fleet's ACL entries unless you build one. 2. **Fragility under chmod.** On a file with named entries, the group-class mode bits address the mask. A configuration-management run applying `chmod -R 750` clamps every named entry at once, with no error and no visible change to the entries themselves. This alone breaks more ACL schemes than any other cause. 3. **Loss in transit.** The entries live in extended attributes, so a restore, a migration, or an `rsync` without `-A` silently drops them, and the group triad left in the mode is the old mask value, which can read wider than the truth. 4. **Drift.** Hand-applied ACLs are not reconciled by anything. Six months later nobody knows whether a given entry is load-bearing or a leftover from an incident. 5. **Departure handling.** Removing someone from a group revokes everywhere. Removing their ACL entries requires finding them first. ## The costs of the alternative Groups are not free either, and a principal-level answer weighs both. Creating a group per shared directory produces its own unmanageable sprawl: hundreds of groups whose names encode paths, a directory service full of single-member groups, and a 16-group-per-user style ceiling in some legacy protocol paths. Group changes are also coarse — you cannot grant read on one directory and write on another to the same person without two groups. So the real boundary is a ratio. When many people need the same access to many paths, that is a role: make it a group. When one or two principals need an exception on one or two paths, a group would be pure overhead: use an ACL. ## The conditions I attach when I do accept an ACL - **Declared, not applied.** The ACL is expressed in the same configuration-management resource that creates the directory, so it is reviewable, reproducible and re-applied after any restore. - **Default ACL set.** Inheritance comes from a default ACL rather than from every writer having the right umask, because a scheme that depends on personal umask settings fails the first time a cron job or a different service writes a file. - **Chmod excluded.** No blanket recursive mode enforcement over that tree, or if there must be one, it sets the mask deliberately rather than incidentally. - **Audited.** A periodic job dumps `getfacl -R` over the managed trees and diffs it against the declared state; the diff is the drift report. - **Documented owner and expiry.** An exception granted for an incident should have a stated end, or it becomes permanent by default. ## Where neither is the right answer Some requests that arrive as "give them an ACL" are actually design smells. If an application needs write access to another application's data directory, the answer may be an API or a queue rather than a shared filesystem. If a person needs read access to production data to debug, the answer may be a copy with sensitive fields removed. If a service account needs broad access across many paths, that is a role — and possibly a signal that the data layout, not the permissions, is wrong. The strongest version of this answer says which requests you push back on, not just which mechanism you pick.
- How would you audit which files across a fleet carry ACL entries?There is no central index, so you build one: a scheduled job that walks the managed trees with `getfacl -R` and stores the dump, then diffs each run against the declared configuration. `ls -l` shows the `+` marker per file, which is fine for one directory and useless at fleet scale. The absence of a native inventory is itself an argument for keeping ACL use rare and declared.
- A configuration-management run applies chmod recursively over an ACL-managed tree. What breaks, and how do you prevent it?On files with named entries the group-class mode bits map to the mask, so the run clamps every named user and group at once — no error, entries still present, access gone. Prevent it by having the same resource own both the mode and the ACL, or by excluding the tree from blanket mode enforcement. Detect it by diffing periodic `getfacl -R` dumps.
- When would you argue that neither an ACL nor a new group is the right answer?When the request reveals a design problem: one service needing write access into another's data directory usually wants an interface, not shared storage; a human needing production read access to debug usually wants a redacted copy; a service account needing many paths is describing a role that the data layout has failed to express. Picking a permission mechanism there just makes the coupling permanent.
A group is a badge the holder carries into every building; an ACL is a name written on the list taped inside one particular door. The badge is easy to revoke; the taped lists have to be found first.
saying these in an interview costs you the question
- Treating ACLs as a drop-in replacement for group design
- Granting ad-hoc ACLs by hand with no record anywhere
- Assuming an ACL grant will survive backups and migrations
- Claiming ACLs are auditable because getfacl exists
- Creating one group per directory and calling it scalable