Access Control List (ACL)

An ACL operates on a first-match principle, evaluating entries sequentially to determine authorization. Each Access Control Entry (ACE) explicitly grants or denies a specific right. The system processes the list until a match is found, making the order of entries critical. A misplaced deny rule can inadvertently block legitimate access, while an overly permissive allow rule at the top can create a security gap. This binary, non-discretionary logic provides a clear, auditable permission path for every access request.

The foundational structure of every ACL is a three-part tuple: Subject, Object, and Permission.

• Subject: The authenticated entity requesting access (user, process, or service account).
• Object: The digital asset being protected (a file, database record, API endpoint, or network socket).
• Permission: The specific operation being authorized (read, write, execute, delete, or modify). This direct binding of a subject to an object is what distinguishes ACLs from broader, role-based models.

Unlike Role-Based Access Control (RBAC), which centralizes permissions around job functions, ACLs are inherently object-centric. Each resource carries its own discrete list of who can interact with it. This model excels in environments with highly sensitive, individualized data where a user's role is insufficient to determine access. For example, a patient record in a healthcare system doesn't just require a 'Doctor' role; it requires an ACL entry explicitly listing the specific treating physicians authorized to view that exact record.

An ACL is a stateless mechanism. Each access request is evaluated in isolation against the current list, with no memory of past decisions. This simplifies the enforcement logic and reduces computational overhead, making it ideal for high-throughput systems like file servers and network routers. However, this statelessness means ACLs cannot natively enforce dynamic, context-aware policies like 'deny access after 5 failed attempts' or 'require a second factor for access from a new location' without being paired with a separate stateful session management system.

ACLs are implemented in two primary security paradigms:

• Discretionary Access Control (DAC): The object's owner has the authority to modify the ACL, granting permissions to other subjects at their discretion. This is common in standard file systems.
• Mandatory Access Control (MAC): A system-wide security policy, not the object owner, dictates the ACL. Subjects and objects are assigned security labels, and the kernel enforces access based on label comparison, overriding owner discretion. This is used in high-security environments.

The primary weakness of ACLs is permission explosion. As the number of users and unique objects grows, managing individual subject-to-object bindings becomes exponentially complex and operationally unsustainable. A company with 10,000 employees and 1 million documents cannot feasibly manage ACLs on a per-user, per-file basis. This is the core driver for adopting Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC), which abstract subjects into groups or evaluate dynamic attributes to collapse the management surface area.