Access Control List

Definition

controlling who can access what

Context

The concept of an access list for computer resources—what we now call an Access Control List (ACL)—originated with the Multics operating system in the mid-1960s. Multics (Multiplexed Information and Computing Service) was a pioneering time-sharing system that introduced many foundational ideas in computer security and operating system design.

ACLs in Multics were designed to specify which users or processes could access specific system resources, and what operations (like read, write, or execute) they were allowed to perform. This was a major step forward from earlier, more monolithic security models, and it laid the groundwork for modern discretionary access control systems.

The idea gained traction and evolved through systems like PRIMOS in the 1980s and later became standardized in various forms, including POSIX ACLs and NFSv4 ACLs. Today, ACLs are ubiquitous in operating systems, firewalls, and network devices, offering fine-grained control over who can do what with digital resources.

The Deep Roots of Access Control

The concept of controlling who can access what—embedded in modern ACLs—has long parallels in governance and law:

Roman and Medieval Authority: Roman systems of imperium granted specific powers to consuls or governors, much like ACLs grant specific rights (read/write/execute) to users. In medieval times, feudal contracts specified land rights and obligations—early role-based delegation, if you will.

Canon Law and Mandates: Religious institutions often operated under strict, recorded permissions for who could perform rites or hold office. These were, in essence, access lists guarded by bureaucratic keys.

Locke, Hobbes, and Delegated Sovereignty: In Enlightenment political philosophy, Locke’s emphasis on consent and Hobbes’s insistence on a sovereign’s absolute authority both wrestle with ideas of who gets access to power and under what constraints—just like a system administrator.

ACLs vs. Role-Based Access Control (RBAC)

ACLs define permissions per object: “Tom can read file.txt, but not write.”

RBAC defines permissions per role: “All ‘engineers’ can read/write project/.”

RBAC reflects organizational hierarchies and job functions, and it scales better in large systems—but it draws from the administrative abstraction seen in bureaucratic states and military structures. It’s governance by groups, not by name.

If we zoom out, both models reflect competing philosophies: ACLs favor individual contracts, while RBAC leans on institutional identity.