Access Control List¶
Artifact — instantiates Least-Privilege Access Design
Lists which actors or groups may take which actions on a specific resource, so that anyone not on the list is denied by default.
An Access Control List (ACL) is the concrete, per-resource record of exactly who may do what to that object. It hangs off the resource, not the actor: the finance folder carries a list saying "these principals, these actions," and the reference monitor consults it every time someone reaches for the folder. The one idea that makes it this mechanism and not a sibling: it is a stored fact, not a computed decision and not a review view. It answers "who can touch this resource?" by enumeration — and by enumeration alone, since anyone with no entry is denied by default. It says nothing about why the access is needed or when it should end; it only records the grant as it currently stands.
Example¶
A shared engineering file server holds a directory, /finance-reports, on a Windows file share. Its ACL has four entries: the group finance-analysts is granted read; the fp-a-leads group gets read and write; the service account backup-svc gets read; and the owner, cfo-office, holds full control, including the right to change the ACL itself. There is no "Everyone" entry. When a product manager in marketing clicks the folder, the reference monitor checks her against the four entries, finds no match, and denies her — she never had to be explicitly forbidden, because the list is closed. Later an analyst moves teams and is removed from finance-analysts; the very next time he opens the folder, the entry no longer matches him and the door is shut. The ACL did its whole job by being an accurate, enforced, per-object list — and none of it required anyone to reason about need.
How it works¶
The distinctive machinery is enumeration bound to an object. Each entry pairs a principal (a user, group, or service account) with a set of allowed actions on this resource; the reference monitor matches an incoming request against the entries and permits it only on a hit, denying by default otherwise. Two properties separate an ACL from its siblings. First, it is identity-based and per-object — in the language of the access-control matrix it is a single column (one object, many subjects), the mirror image of a capability, which is a row (one subject, many objects). Second, some entries carry a grant or owner right that permits the holder to modify the list — the hook by which the ACL bounds who may re-share the resource onward. The ACL stores the answer; it does not derive it and it does not display it across actors for review.
Tuning parameters¶
- Entry granularity — individual principals vs. groups. Groups cut maintenance but hide effective access behind nested membership no one re-reads.
- Permission bit set — coarse read/write vs. fine-grained (delete, execute, change-permissions, take-ownership). Finer bits scope tighter but multiply what must be audited.
- Inheritance — whether child objects inherit the parent's ACL or carry explicit ones. Inheritance scales; explicit per-object ACLs are precise but drift-prone.
- Default / catch-all entry — whether an "Everyone" or "Authenticated Users" entry exists. Any broad catch-all quietly defeats deny-by-default and should usually be empty.
- Grant/owner rights — how many principals may edit the list. More editors means faster change and faster uncontrolled re-sharing.
When it helps, and when it misleads¶
Its strength is an unambiguous, enforceable, auditable snapshot of who-can-touch-this-object — the ground-truth record the whole design ultimately rests on. It is also cheap and universal: every filesystem, bucket, and queue has one.
Its failure mode is that an ACL is static and identity-based, so it drifts. Nobody removes stale entries; group nesting obscures the real reach; and the list has no concept of need or expiry, so a grant that was right in 2021 survives untouched into 2026. The classic misuse is the confused deputy[1]: a privileged program uses its own ACL rights on behalf of a less-privileged caller, so the list says "allowed" while the actual authority came from the wrong place. The discipline that guards against this is to never treat the ACL as self-maintaining — pair it with an external expiry and review path, keep groups shallow, and refuse the tempting "Everyone" entry so that deny-by-default actually holds.
How it implements the components¶
permission_scope— each entry names the exact actions a principal may take on the resource (read, write, delete, administer); the ACL is where the granted scope is written down.access_boundary— the list is the boundary: listed principals are inside, everyone else is default-denied, with no reasoning in between.delegation_boundary— the grant/owner right on an entry bounds whether and by whom the ACL may be extended to others, capping onward re-sharing.
It records grants but does not decide whether that access is genuinely needed (task_need_definition — that's Need-to-Know Policy) nor when it should expire (revocation_trigger — that's Access Recertification); and it stores access one object at a time rather than laying every actor and resource out for review (resource_map, actor_role_map — that's Permission Matrix).
Related¶
- Instantiates: Least-Privilege Access Design — the ACL is the per-resource record of record that the whole design enforces against.
- Sibling mechanisms: Permission Matrix · Need-to-Know Policy · Access Log Review · Access Recertification · Attribute-Based Access Policy · Role-Based Access Control · Approval Workflow · Temporary Privilege Elevation
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: The mechanism is the per-object configuration that binds principals to allowed actions and forms the resource's enforced permission boundary, so its operative form is an enduring configured access arrangement.
Nearest alternative: Representation, Specification & Plan — The list is not merely a descriptive artifact: its entries constitute the live permission configuration evaluated by the reference monitor.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Per-object principal-action lists, reference-monitor checks, deny-by-default behavior, inheritance, and delegation rights are canonical operating-system and information-security access-control constructs.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
An ACL and a capability are the same information read two ways: the ACL indexes by object ("who can touch this file?"), a capability indexes by subject ("what can this actor touch?"). Least-privilege designs almost always store the object view because resources are what get protected and audited — but the choice has consequences, since revoking a single actor's reach means editing every object's ACL, whereas a capability model would revoke it in one place. Knowing which view you hold explains why some revocations are cheap and others are a sweep. This is also why the ACL differs from Attribute-Based Access Policy: the ACL stores the answer per object, while the attribute policy computes it fresh per request.
References¶
[1] Hardy, N. "The Confused Deputy: (or Why Capabilities Might Have Been Invented)". ACM SIGOPS Operating Systems Review 22(4): 36–38 (1988). Shows how an ACL-protected compiler can be induced by its caller to exercise the compiler’s own authority against a protected file. registry ↩