Difference between revisions of "Access Control List"

Latest revision as of 14:36, 26 June 2025

Definition

An Access Control List (ACL) is a data structure used in computer systems to define which users or system processes are allowed to access specific resources, and what operations they’re

Context

Each entry in an ACL typically includes:

• A subject (like a user or group)
• A set of permissions (e.g., read-only, full control)

For example, an ACL on a file might say:

• Alice: read, write
• Bob: read

ACLs are used in:

• Operating systems (e.g., Windows, Linux) to manage file and folder permissions
• Network devices (like routers and firewalls) to filter traffic based on IP addresses, ports, or protocols
• Databases to control access to tables, views, or even individual fields
• They’re foundational to discretionary access control (DAC) models

History

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.

In Windows, Access Control Lists (ACLs) are embedded in the security descriptors of securable objects—like files, folders, registry keys, and even Active Directory objects. You can view and manage them through both graphical tools and command-line utilities. ACLs are stored in the Discretionary Access Control List (DACL) and optionally a System Access Control List (SACL) for mandatory control elements within the object’s security descriptor. You can programmatically access or modify them using Windows API functions like GetSecurityInfo, SetEntriesInAcl, and SetSecurityInfo

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 Identifiers, while RBAC leans on institutional role Identifiers.

References