Category: Access Control Models

Discretionary Access Control

Also known as:

Simply put

Discretionary Access Control (DAC) is an access control approach in which the owner of a resource decides who else can use it and what they can do with it. Because control rests with individual resource owners rather than a central authority, DAC is flexible but distributes access decisions across many users. It is commonly seen in familiar systems such as file-sharing permissions and smartphone apps.

Formal definition

DAC is an access control model, defined in the Trusted Computer System Evaluation Criteria (TCSEC), in which access to an object is governed at the discretion of that object's owner or another subject holding the appropriate permission. It is enforced over all subjects and objects in a system, and its policy is typically decentralized: owners can grant, modify, or revoke access rights to other subjects, and in most implementations permissions can be propagated onward. This model concerns authorization (what a subject may do with an object) and presupposes that identification and authentication have already established the subject's identity; it does not itself perform authentication. DAC contrasts with Mandatory Access Control (MAC), where a central authority, rather than resource owners, sets access policy. The owner-driven flexibility of DAC is a defining trait; its limitations (for example, weaker containment of privilege propagation compared with MAC) depend on the specific system and configuration.

Why it matters

DAC is one of the most widely encountered access control models in everyday computing, underlying file-sharing permissions, smartphone app data access, and countless operating system authorization mechanisms. Its owner-driven flexibility makes it well suited to environments where the people closest to a resource are best positioned to decide who should use it, allowing access decisions to be made quickly without routing every request through a central authority. For IAM practitioners, understanding DAC is foundational because so many familiar systems default to it, and because its behavior shapes how access rights spread through an environment.

That same flexibility is also the source of DAC's principal governance challenge. Because control rests with individual resource owners rather than a central authority, access decisions become distributed across many users, and in most implementations permissions can be propagated onward from one subject to another. This decentralization can make it harder to maintain a consistent, auditable view of who can access what, and it weakens containment of privilege propagation compared with a centrally governed model such as Mandatory Access Control (MAC). The degree to which this is a problem depends heavily on the specific system and its configuration.

For identity governance and compliance teams, DAC environments therefore often require compensating controls such as periodic access reviews and certification to detect access that has drifted from intended policy. Recognizing when a system relies on DAC helps architects decide where owner discretion is acceptable and where a more centralized model is warranted.

Who it's relevant to

Security Architects

Architects choosing among access control models need to weigh DAC's owner-driven flexibility against its weaker containment of privilege propagation relative to MAC. Understanding where a system defaults to DAC helps them decide where owner discretion is appropriate and where a more centralized policy model is required.

IAM Engineers

Engineers implementing or integrating systems that rely on DAC must account for its decentralized nature, where owners can grant, modify, and revoke access and, in most implementations, permissions can be propagated onward. This affects how access is provisioned and how consistently it can be enforced across subjects and objects.

Identity Governance Leads

Because DAC distributes access decisions across many resource owners, governance leads often cannot rely on a single central policy to know who can access what. Periodic access reviews and certification become important compensating controls for detecting access that has drifted from intended policy in DAC-based environments.

Compliance Officers

Compliance officers should recognize that DAC's decentralized control and the potential for permissions to propagate onward can complicate demonstrating that access aligns with policy. The audit burden and control expectations depend on the specific system and configuration.

System Administrators

Administrators regularly manage DAC in familiar systems such as file-sharing permissions and smartphone apps, where resource owners directly control who can use their resources. Awareness of how rights are granted and propagated in these systems is essential to keeping access aligned with intended use.

Inside DAC

Owner-controlled permissions

In DAC, the owner of a resource (such as the user who creates a file) has the discretion to grant or revoke access rights to other principals. Control over the resource rests with the owner rather than being centrally mandated by a system-wide policy.

Access Control List (ACL)

A common mechanism for expressing DAC permissions, associating a resource with a list of principals (users or groups) and the specific rights (for example read, write, execute) each is granted. ACLs are evaluated at access time to authorize or deny requests.

Permission propagation and delegation

Because owners can pass on rights, a principal granted access may, depending on configuration, be able to grant that access to others. This discretionary delegation is a defining characteristic and a source of DAC's flexibility.

Identity-based access decisions

DAC authorization decisions are typically made based on the identity of the requesting principal (or group membership) matched against the resource's permission settings, following prior identification and authentication of that principal.

Contrast with MAC

DAC differs from Mandatory Access Control (MAC), where access is governed by system-enforced policy and security labels that individual owners cannot override. In DAC the owner holds discretion; in MAC a central authority does.

Common questions

Answers to the questions practitioners most commonly ask about DAC.

Is DAC the same thing as RBAC because both involve granting permissions?

No. DAC and RBAC are distinct access control models. In DAC, access decisions are at the discretion of the resource owner, who can directly grant or revoke permissions on objects they own. RBAC assigns permissions to roles, and principals gain access by being members of those roles rather than through owner-driven grants. The defining characteristic of DAC is owner discretion over their own objects, not the structural mapping of permissions to roles. The two can coexist in a system, but they should not be treated as interchangeable.

Does DAC mean access control is weaker or less secure than MAC by definition?

Not inherently. DAC and MAC (mandatory access control) differ in who controls access decisions, not in an absolute measure of security. Under DAC, owners set permissions at their discretion; under MAC, access is governed by system-enforced policy and labels that users typically cannot override. DAC can be appropriate in many contexts and problematic in others, particularly where owner discretion allows permissions to propagate in ways that are hard to constrain. Whether one model is preferable depends on the deployment's threat model, compliance requirements, and need for centralized policy enforcement rather than on any universal ranking.

How is DAC typically implemented on file systems?

In most operating system deployments, DAC is implemented through mechanisms such as access control lists (ACLs) or owner/group/other permission bits associated with each object. The object's owner can typically modify these settings to grant or revoke access to other principals. The specific structure, granularity, and inheritance behavior of these permissions vary considerably by operating system and file system, so exact capabilities should be confirmed against the platform in use.

What is a common concern when relying on DAC for authorization?

A frequently cited concern is that owner discretion can lead to permission sprawl and inconsistent enforcement, because individual owners grant access without a central policy check. Depending on configuration, permissions granted by one owner may also be re-shared by recipients, which can make it difficult to reason about who ultimately has access. Organizations often supplement DAC with governance controls such as periodic access reviews to detect and remediate accumulated grants, though those governance functions are separate from DAC's runtime enforcement itself.

Can DAC be combined with other access control models in the same system?

Yes, in many deployments DAC operates alongside other models. For example, a system may enforce mandatory policy constraints while still allowing owners discretionary control within the bounds that policy permits, or it may layer role-based assignments over owner-managed object permissions. The exact interaction and precedence between models depends on the platform and its configuration, so the combined behavior should be validated in the specific environment rather than assumed.

How should DAC-managed permissions be audited over time?

Because DAC allows owners to change permissions at their discretion, auditing typically focuses on periodically capturing the current state of grants on objects and comparing them against expected access. This is generally handled through governance and administration processes such as access certification and reviews, which are distinct from the runtime enforcement DAC performs. The available audit detail depends on whether the underlying platform logs permission changes and to what granularity, which varies by implementation.

Common misconceptions

DAC is inherently insecure and should always be replaced by MAC or RBAC.

DAC is not universally inferior; it offers flexibility that suits many collaborative and general-purpose environments. Its suitability depends on the deployment context, and MAC, RBAC, or ABAC address different requirements rather than being categorically better.

DAC handles authentication or verifies who a user is.

DAC is an authorization model that determines what an already-authenticated principal may do. Identification and authentication are separate, prior steps; DAC governs the access decision only after identity has been established.

In DAC, only administrators can change permissions.

A defining feature of DAC is that the resource owner, not solely a central administrator, has the discretion to grant or revoke access. This delegation of control is what distinguishes discretionary control from mandatory, centrally enforced models.

Best practices

Since owners can delegate access, periodically review resource ACLs and effective permissions to detect unintended propagation and access creep.

Apply least privilege when owners grant rights, limiting delegation to what each principal genuinely requires rather than broad read/write access.

Ensure identification and authentication controls are robust upstream, because DAC authorization decisions rely on the correctness of the established principal identity.

Assess whether DAC alone meets your assurance requirements; where centrally enforced policy is needed, consider layering or substituting MAC, RBAC, or ABAC as appropriate to the deployment.

Document ownership and delegation chains so that responsibility for access grants remains auditable, given that discretion is distributed to owners rather than centralized.