Discretionary Access Control (DAC): the owner decides

From “who are you” to “what may you do”

The previous module answered a single question in many ways: who are you? Factors, MFA, biometrics, SSO, and sessions are all machinery for authentication — proving identity. This module turns to the other half of access: once we know who you are, what are you allowed to do? That is authorization, and the family of models that answer it are often nicknamed xBAC — DAC, MAC, RBAC, ABAC, PBAC, ReBAC, NGAC — because most of them end in “Based Access Control.”

We start where access control itself started: Discretionary Access Control (DAC), the oldest and still the most widespread model. Its defining idea is in the word discretionary — access is left to the discretion of the owner. If you create a file, you own it, and you decide who else may read or change it. The system faithfully enforces whatever you choose, but it does not impose a policy of its own. Every time you right-click a document and pick “Share,” or run chmod on a script, you are exercising DAC.

DAC was formally named in the U.S. Department of Defense’s 1985 Trusted Computer System Evaluation Criteria (the “Orange Book”), which defined it as a means of restricting access “based on the identity of subjects and/or groups to which they belong,” with the crucial property that a subject with a given access permission is “capable of passing that permission on to any other subject.” That last clause — the ability to pass permissions along — is both DAC’s great convenience and its fundamental weakness, and it will run through this entire article.

The access control matrix: the model beneath the models

Before DAC, MAC, or RBAC, there is one abstract structure that all of them are ways of expressing: the access control matrix, described by Butler Lampson in 1971. Picture a giant grid. Every subject (user, process) is a row. Every object (file, device, record) is a column. Each cell lists the rights that subject has over that object: read, write, execute, own, delete.

The matrix is a perfect conceptual model and a terrible practical one: for thousands of users and millions of objects it would be mostly empty and impossibly large to store. So real systems never store the matrix directly. Instead they store it sliced one of two ways, and that choice defines two whole traditions of access control.

Slicing by column: Access Control Lists (ACLs)

Take one object and list everyone who may touch it. That column of the matrix, attached to the object, is an Access Control List. A file says, in effect, “Sara can read and write me; Daniel can read me.” ACLs answer the question “who can access this object?” instantly, because the answer lives with the object. This is how filesystems work, and it is the dominant way DAC is implemented.

Slicing by row: capabilities

Take one subject and list everything they may touch. That row, held by the subject, is a set of capabilities — unforgeable tokens that each say “the holder may do X to object Y.” A capability answers “what can this subject access?” instantly. Capabilities are less common in mainstream filesystems but reappear everywhere in modern systems: a signed URL, an OAuth bearer token, a Kubernetes service-account token, and a file descriptor are all essentially capabilities — possession is permission.

flowchart TD
  accTitle: How Discretionary Access Control decides a request
  accDescr: An owner sets the access control list on an object at their discretion, including granting rights to other subjects. When a subject makes a request to the object, a reference monitor intercepts it and consults the object's access control list. If the list grants the requested right, access is allowed; otherwise it is denied. A separate arrow shows that a subject who has been granted a right, including the grant option, can pass that right to another subject, illustrating rights propagation.
  OWN[Owner] -->|sets at discretion| ACL[Object's Access Control List]
  OWN -->|grants rights to| SUBJ[Other subjects]
  REQ[Subject requests access] --> RM{Reference monitor}
  RM -->|consults| ACL
  ACL -->|right present| ALLOW[Allow]
  ACL -->|right absent| DENY[Deny]
  SUBJ -.->|can pass right along| SUBJ2[Yet another subject]

A short history: why “discretionary” is a defense term

It is easy to assume file permissions are just an engineering convenience, but the vocabulary comes from defense research, and the history explains the model’s shape. In the 1960s, Multics pioneered per-segment ACLs and the ring-protection ideas that Unix later simplified into owner/group/other bits. In 1985, the U.S. Department of Defense published the Trusted Computer System Evaluation Criteria (the Orange Book), which formally separated two kinds of control: discretionary (owner-driven, the subject of this article) and mandatory (label-driven, the next). The word “discretionary” exists precisely to contrast with “mandatory” — it names the fact that policy is left to a user’s discretion rather than imposed by the system.

That framing was not academic. The Orange Book was a procurement standard: to sell systems to the government you had to meet an evaluated class, and higher classes required mandatory controls because discretionary ones were understood to be insufficient for classified data — for exactly the trojan-horse reasons above. So when you chmod a file today, you are using a mechanism that a 40-year-old security standard classified as the weaker of two tiers, kept because it is indispensable for everyday work. Knowing that lineage is what keeps DAC in proportion: not a flaw to be eliminated, but a deliberately limited tool that the rest of the field was built to complement.

The reference monitor: the thing that actually says “no”

DAC describes who decides policy, but something has to enforce it on every single access, without exception, and without being bypassable. That something is the reference monitor — a concept as old as access control theory itself. A reference monitor must be three things: always invoked (no access path skips it), tamperproof (nothing can disable or edit it), and small enough to verify (so you can actually trust it). In an operating system, the kernel’s access check is the reference monitor; in a web application, it is the authorization middleware every request passes through.

This matters for DAC because owner discretion is only as good as the gate that enforces it. If an attacker can reach a file through a path that skips the permission check — a misconfigured NFS export, a backup exposed without ACLs, a debug endpoint that reads files directly — then the owner’s careful chmod means nothing. Every model in this module ultimately assumes a working reference monitor underneath it. When you later meet the Policy Enforcement Point in the authorization-architecture module, recognize it as the reference monitor idea, promoted to a first-class, network-scale component.

DAC in the wild #1: Linux file permissions

The canonical DAC implementation sits on the machine you are probably reading this on. Every file in a Unix-like system has an owner, a group, and three sets of permission bits — read (r), write (w), execute (x) — for the owner, the group, and others. Run ls -l and you see it:

-rwxr-x---  1 sara  finance  8451 Jul 15 09:03 deploy.sh

Reading left to right after the file-type dash: the owner sara has rwx (read, write, execute); the finance group has r-x (read and execute, no write); everyone else has --- (nothing). The owner set this, and the owner can change it at any moment with chmod, or hand the file to another owner with chown. That discretion is the whole point — no administrator had to approve it, and no central policy dictated it. sara decided.

Permissions are often written in octal: each rwx triple becomes a digit (r=4, w=2, x=1), so -rwxr-x--- is 750. chmod 640 report.txt means owner read+write, group read, others nothing. It is worth internalizing this because it is the most common access control notation in the world, and every DevOps incident review eventually includes someone discovering a secret file left at 644 (world-readable) when it should have been 600.

POSIX ACLs: DAC beyond owner/group/other

The three-tier owner/group/other model is coarse: what if sara wants to give exactly one other user, david, write access, without adding him to the finance group? Classic bits cannot express that. POSIX ACLs extend the same discretionary model with named entries. With setfacl -m u:david:rw report.txt, sara grants david read-write directly; getfacl lists the full set. This is still pure DAC — the owner is extending their own discretionary grants to a wider, more precise audience — but it removes the expressiveness ceiling of the classic three tiers. It is the bridge from “owner/group/other” toward the arbitrary who-can-do-what of a full ACL.

Capabilities are not a museum piece

It is tempting to file capabilities under “history,” but they quietly run modern infrastructure. A file descriptor you pass to a child process is a capability. A pre-signed S3 URL is a capability: whoever holds the link can fetch the object, no identity check required. An OAuth bearer token, a Kubernetes service-account token, a JWT in an Authorization header, a database connection string — all are capabilities in the strict sense: possession is permission. The object-capability model takes this to its conclusion and builds whole systems where the only way to act on a resource is to hold a reference to it, which supports a very clean form of least authority — a component can only affect what it was explicitly handed. The reason this matters here is that capabilities inherit DAC’s propagation trait in the sharpest form: a capability is trivially copyable and, as we will see, painfully hard to revoke.

DAC in the wild #2: Windows DACLs

Windows makes the ACL model explicit and central. Every securable object (file, registry key, service, printer) carries a security descriptor, and inside it a Discretionary Access Control List (DACL) — the name itself tells you the model. The DACL is an ordered list of Access Control Entries (ACEs), each of which grants or denies a specific right (read, write, delete, take-ownership) to a specific security principal (a user or group identified by a SID).

When a process tries to open an object, the Windows kernel walks the DACL entry by entry, accumulating granted rights and honoring explicit deny ACEs first, until it has enough to satisfy the request — or runs out and denies. The object’s owner can always modify the DACL, which is precisely what makes it discretionary. Windows layers a lot on top of this — inheritance from parent containers, a separate SACL for auditing — but the core is a per-object ACL that the owner controls. It is DAC with an enterprise-grade surface.

Why ACE order is a security decision

That phrase “honoring explicit deny ACEs first” hides a real trap. An ACL is not a set; it is an ordered list, and evaluation stops as soon as the accumulated rights satisfy the request. Put an allow entry before a deny entry that was meant to override it, and the deny may never be reached. This is why Windows imposes a canonical order (explicit denies, then explicit allows, then inherited entries) and why mixing “deny” and “allow” ACEs by hand is a classic source of accidental over-permission. The lesson generalizes: any ACL system that supports negative entries makes ordering part of the policy, and an ACL that is correct as a set can still be wrong as a list. Prefer expressing intent through positive grants to narrow audiences over stacking denies on broad ones.

DAC in the wild #3: databases and the cloud

Discretionary control is everywhere once you learn to see it. In SQL, GRANT SELECT ON accounts TO daniel is a discretionary grant; add WITH GRANT OPTION and you have literally handed Daniel the DAC propagation right — he can now grant SELECT to others, and the access spreads outward from the original owner. Cloud object stores began the same way: Amazon S3 object ACLs let an object owner grant read to specific accounts, though AWS now steers customers away from ACLs toward centrally managed policies precisely because unmanaged discretionary grants are hard to govern at scale.

And every consumer collaboration tool is DAC at heart. When you press Share on a Google Doc and type a colleague’s email, you are the owner adding an ACE to that document’s ACL. When you grant “Editor” and they can re-share it, you have handed over the grant option. The entire experience of modern collaborative software is a friendly face on Discretionary Access Control.

The trojan horse problem: DAC’s original sin

DAC is convenient, intuitive, and ubiquitous — and it has a structural weakness that no amount of careful configuration fixes. DAC controls access to objects, but it does not control what happens to the information after access. Once a subject can read data, the model has no say over whether they copy it, forward it, or paste it somewhere world-readable.

The classic illustration is the trojan horse. Suppose sara has read access to a sensitive file. daniel, who does not, gives sara a useful-looking tool — a formatter, a linter, anything. When sara runs it, that program executes with Sara’s rights. Nothing stops it from quietly reading the sensitive file (which Sara may read) and writing a copy to a location Daniel controls. Sara never intended to leak anything; the program abused the rights she legitimately holds. DAC cannot prevent this, because from the system’s view the access was perfectly authorized — it was Sara reading her own file.

This is also called the confused deputy problem, named by Norm Hardy in 1988 after a real case: a compiler that could write billing records to a protected directory was asked by an ordinary user to write its output there, and dutifully overwrote the billing file — misusing its own authority on a user’s behalf. A program with privileges is tricked into wielding them for someone who lacks them. It is the fundamental reason high-security environments cannot rely on DAC alone: discretionary permissions travel with the process, not with a policy about the data, so information flows wherever running code carries it. Controlling that flow is exactly what Mandatory Access Control was invented to do — the subject of the next article.

Strengths and weaknesses, honestly

DAC dominates for real reasons, and it fails for equally real ones. Holding both in view is the point of studying it.

Strengths. It is simple and intuitive — ownership maps to how people already think about their stuff. It is flexible and immediate: no ticket, no administrator, no policy review to share a file with a colleague. It is decentralized, which means it scales socially — millions of users manage their own resources without a bottleneck. And it is universal: every operating system, database, and collaboration tool speaks it, so it is the lingua franca of access.

Weaknesses. There is no central policy — the organization cannot easily state or enforce a rule like “no one outside Finance may ever read payroll,” because each owner decides independently. Grants accumulate into privilege creep, and because they are scattered across objects, they are hard to audit (“who can read this?” is answerable per file; “everything Daniel can reach” is not). It is vulnerable to malware and the confused deputy, since running code inherits the user’s rights. And it provides no information-flow control — the trojan-horse leak above is invisible to it. In short: DAC optimizes for the owner’s convenience, not the organization’s assurance.

Revocation: the quiet failure

Granting is easy under DAC; taking access back is where it quietly falls apart. With ACLs, revocation is at least locatable in principle — you edit the object’s list — but in practice grants are scattered across thousands of objects, so fully revoking a person means finding every ACE they appear in, everywhere, which no owner-driven system tracks centrally. With capabilities it is worse: once you have handed out an unforgeable token that says “the holder may read X,” you generally cannot un-issue it. The classic fixes are all awkward — add a layer of indirection so you can invalidate the target, give capabilities short lifetimes so they expire, or maintain a revocation list that you must then check on every use (which quietly turns your capability back into an ACL lookup).

You have already seen this tension in the previous module: revoking a session or an OAuth token is hard for exactly the same reason — a bearer token is a capability. Recognizing revocation as a general weakness of discretionary, possession-based access — not a quirk of one system — is one of the most useful things to carry out of this article. When an auditor asks “prove this former contractor can no longer reach anything,” a DAC-only estate cannot answer cleanly, and that gap is a direct driver of the more centralized models ahead.

A worked example: the shared research folder

Make it concrete. Sara owns a folder /research/roadmap and sets it to 750 — she has full access, her product group can read and execute (browse), others get nothing. Daniel, in support, needs one document. Sara adds a POSIX ACL: setfacl -m u:daniel:r /research/roadmap/q3.pdf. Clean, immediate, no admin involved — DAC at its best.

Now the cracks show. Daniel, helpful as ever, forwards q3.pdf to a partner over email — DAC never controlled the copy. A month later, security asks “who has access to the roadmap?” and there is no single place to answer it; the grants are spread across the folder, individual file ACLs, and group membership. Then Daniel leaves the company: his personal ACL entry on q3.pdf lingers because no central process knows to remove per-file discretionary grants. Every one of these problems is DAC being exactly what it is — owner-driven and decentralized — and every one of them is a reason the later models add structure on top.

Contrast how the same folder behaves once a central model is layered on. Under RBAC, access to /research would flow from a role (“Product — Roadmap”) that a joiner-mover-leaver process attaches and detaches automatically, so Daniel’s departure removes his access in one place and the “who can read this?” question has a single authoritative answer. Under MAC, q3.pdf might carry a Confidential label that forbids export to an unclassified channel outright, so Daniel could not have emailed it in the first place. DAC did nothing wrong here — it did exactly what its owner told it — but “exactly what the owner told it” is not the same as “what the organization needs,” and that gap is the reason every remaining article in this module exists. Keep this folder in mind; we will re-solve it, better, with each new model.

Where DAC fits among the models

DAC is not “wrong” — it is a layer. In practice modern systems stack models: the filesystem enforces DAC bits, SELinux enforces MAC labels above them, the application enforces RBAC roles, and a policy engine may enforce ABAC rules on top of that. A request must satisfy all the layers that apply. DAC is almost always the bottom layer — the owner-driven baseline — with more centralized models added where the organization needs guarantees that owner discretion cannot provide.

Understanding DAC first is what makes the rest of the family legible. RBAC exists because managing thousands of individual discretionary grants does not scale, so we group permissions into roles. ABAC exists because roles cannot capture context like time and location. MAC exists because discretion itself is the risk when information must not flow. Each model in this module is, in part, an answer to something DAC cannot do.

The table below previews that framing — read it now as a map of the module, and again after each article, when the trade-offs will mean more.

Notice that DAC sits alone in one respect: it is the only model in the family where an ordinary end user routinely authors policy. Every other model moves that authorship toward administrators, security teams, or formal policy — trading the immediacy of DAC for control, scale, and auditability. That trade is the through-line of the entire module.

Recap

Discretionary Access Control is the foundation the rest of authorization is built against:

1. The owner decides. Access is set at the discretion of the resource owner, who can grant rights to others — and grantees can often pass those rights along (the propagation property from the Orange Book definition).
2. It is the access control matrix, sliced by object. DAC is normally implemented as ACLs (rights stored with the object); capabilities are the same matrix sliced by subject and reappear as tokens and signed URLs.
3. It runs the world. Linux permissions and POSIX ACLs, Windows DACLs, SQL GRANT, S3 object ACLs, and every “Share” button are DAC.
4. Its weakness is propagation, not access. DAC controls who opens an object but not what happens to the data after — hence the trojan-horse / confused-deputy problem and the lack of information-flow control.
5. It is a layer, not the whole story. DAC is the owner-driven baseline; MAC, RBAC, and ABAC add the central policy, scalability, and context it cannot.

Three questions to test yourself

1. A colleague says “we use ACLs, so we’re not doing DAC.” Explain why that statement confuses a model with an implementation, and describe a case where an ACL-based system would nonetheless enforce a non-discretionary policy.
2. Walk through the trojan-horse attack in your own words for a program a user downloads and runs. Which exact property of DAC makes the leak possible, and name one model from later in this module that would prevent it.
3. Your manager wants to answer “who can read the payroll file?” and “everything Daniel can access” from the same system. Which of those two questions does an ACL answer cheaply, which does a capability answer cheaply, and why can neither answer both well?

Hands-on exercises

1. Read a real ACL. On any Linux or macOS machine, create a file, run ls -l to read its mode, then change it with chmod and watch the bits move. If your system supports it, use setfacl/getfacl (Linux) or ls -le (macOS) to add and inspect a named-user ACL entry. Write down the octal mode for “owner read-write, group read, others none.”
2. Find the propagation right. In a database you can access (even SQLite is fine conceptually), or in a cloud IAM console, locate the mechanism equivalent to WITH GRANT OPTION — the setting that lets a grantee re-grant. Note who, in your environment, currently holds it, and whether that is intentional.
3. Audit a discretionary sprawl. Pick a shared folder (Google Drive, SharePoint, a network share). List everyone who has access and how they got it (direct share, group, inheritance, re-share). Notice how hard it is to get a complete answer — that difficulty is the governance weakness of DAC, and it is the problem RBAC sets out to tame.