How does a discretionary access control list work?

How DACLs actually grant or block access

A discretionary access control list works by attaching permissions directly to an object such as a file, folder, database record, or shared resource. Each entry names a user, group, or sometimes a role and then states what that subject may do, such as read, write, execute, delete, or take ownership. Because the owner controls the list, access decisions can change quickly without a central policy update.

The practical effect is flexibility. A DACL can give one user full control, another read-only access, and a group limited edit rights on the same object. That makes it useful in environments where the object owner knows who should collaborate, but it also means the security decision is only as strong as the owner's judgment and account protection.

In many systems, a DACL is evaluated after the subject proves its identity and before the system allows the requested action. The list therefore acts as the object-level gatekeeper, not the whole authorization model. For broader access-governance context, an Authorisation Models Guide helps compare discretionary control with role-based, attribute-based, and relationship-based approaches.

Why DACLs are powerful, and where they become fragile

DACLs are easy to understand because they map to the real owner of the object, but that same property creates risk. If the owner account is compromised, the attacker can often rewrite the list, grant broader access, or remove restrictive entries. Stale entries, inherited permissions, and group sprawl can also make a DACL look tighter than it really is.

The model is especially fragile when ownership is loosely defined or when users can delegate access without review. In those cases, the list becomes a record of accumulated convenience rather than a trustworthy control. A broad IAM baseline is useful here, and the IAM and IGA Basics guide is a good companion for understanding why ownership, entitlement review, and removal of dormant access matter.

DACLs also become harder to reason about when many layers of access intersect, such as file system permissions, application roles, and downstream sharing settings. The more places a user can inherit or receive access, the more likely it is that the effective permission set differs from the visible list. For application-side access failures, the Broken Access Control Prevention Guide shows how object-level checks fail when systems trust the wrong subject or ignore ownership.

How to manage DACLs without turning them into permission sprawl

Good DACL administration is less about creating entries and more about keeping them minimal, reviewable, and tied to current business need. Keep lists short where possible, prefer groups over individual one-off grants when the system supports that pattern, and remove access that no longer has a clear owner or purpose. If the control is used for sensitive data, treat permission review as a recurring task rather than a one-time setup.

What to verify: confirm who owns the object, who can change the list, and whether any entries were added for temporary work that were never removed. Also check whether the object supports inheritance, because inherited entries can hide the real effective access even when the visible DACL looks clean. In practice, weak privilege management is often where the control fails first, so the Database Credential and Access Security Guide is a useful example of how access governance changes when the protected object can be reached through shared or privileged paths.

Risk and Threat Considerations

DACLs concentrate power in the object owner, which means account compromise can become permission compromise very quickly. They also create a soft target for abuse when old entries, broad groups, or delegated admins remain in place after the original business need has passed.

Failure mechanism: An attacker who gains control of the owner or another privileged administrator can alter the list, add themselves or a controlled account, and preserve access even after the initial compromise is noticed.

Impact: Unauthorized reads, writes, or deletions can follow, and the resulting access may be hard to distinguish from legitimate owner-approved changes unless permission history is retained and reviewed.

Practitioner Guidance

What to verify: Check who can modify the ACL, not just who can use the object. If the owner role is shared, delegated, or automated, confirm that those pathways are separately protected and monitored.

Common mistake: Treating the visible list as the full picture. Effective access may include inherited permissions, group membership, application-side exceptions, and break-glass paths that do not appear obvious in a quick review.

Practitioner takeaway: A DACL is only trustworthy when ownership is stable, permission changes are reviewable, and stale entries are removed before they become standing access.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?
• What is the difference between reviewing human access and reviewing NHIs?