Discretionary Access Control (DAC): the owner decides

The roadmap that walked out the door

Sara, an engineer on the product team, owns a folder called /research/roadmap. She sets it so that she has full access, her product group can browse and read it, and nobody else sees anything. Daniel, who works in support, needs one document from it to answer a customer, so Sara gives him read access to q3.pdf with a single command. No ticket, no administrator, done in ten seconds. A week later Daniel, trying to be helpful, emails the PDF to a partner. A month after that, security asks who has access to the roadmap, and nobody can give a complete answer. When Daniel leaves the company, his personal permission on q3.pdf stays behind, because nothing central knows it exists.

Every one of those events is discretionary access control (DAC) doing exactly what it was designed to do. The previous articles answered one question in many ways: who are you? Factors, MFA, biometrics, SSO, and sessions are all machinery for authentication. From here the domain turns to the other half of access: once we know who you are, what are you allowed to do? That’s authorization, and the family of models that answer it is 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. DAC is the oldest model and still the most widespread, and its defining idea is in the word: 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 imposes no policy of its own. Every time you right-click a document and pick “Share,” or run chmod on a script, you’re using DAC.

The access control matrix

Before DAC, MAC, or RBAC, there’s one abstract structure they all express in different ways: the access control matrix that Butler Lampson described in 1971. Picture a huge grid. Every subject, a user or a process, is a row. Every object, a file, a device, a record, is a column. Each cell lists the rights that subject has over that object: read, write, execute, own, delete.

As a concept the matrix is perfect; as an implementation it’s hopeless. With thousands of users and millions of objects it would be enormous and almost entirely empty. So real systems never store it directly. They store it sliced one of two ways, and that choice defines two whole traditions.

Slice it by column and you take one object and list everyone who may touch it. That column, attached to the object, is an access control list (ACL). A file says, in effect, “Sara can read and write me; Daniel can read me.” ACLs answer “who can access this object?” instantly, because the answer lives with the object. This is how filesystems work, and it’s the dominant way DAC is implemented.

Slice it by row and you 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.” Capabilities answer “what can this subject reach?” instantly. They’re less common in mainstream filesystems but turn up everywhere in modern systems: a signed URL, an OAuth bearer token, a Kubernetes service account token, and a file descriptor are all capabilities in effect, where holding it is the permission.

ACLs and capabilities aren’t rival technologies so much as the same matrix seen from two sides. ACLs live with the object and are easy to review per resource. Capabilities live with the subject, are easy to review per user, and are easy to delegate. Most real systems are built on ACLs and add capabilities wherever delegation matters.

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]

Why “discretionary” is a defense term

File permissions look like a plain 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 protection rings that Unix later simplified into owner, group, and 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, driven by owners, and mandatory, driven by labels, the subject of the next article. It defined DAC as restricting access “based on the identity of subjects and/or groups to which they belong,” with the crucial property that a subject holding a permission is “capable of passing that permission on to any other subject.” That ability to pass permissions along is DAC’s great convenience and its fundamental weakness, and it runs through this whole article.

The Orange Book was a procurement standard. To sell systems to the U.S. government you had to meet an evaluated class, and the higher classes required mandatory controls because discretionary ones were understood to be insufficient for classified data. So when you chmod a file today, you’re using a mechanism that a forty-year-old security standard classed as the weaker of two tiers, kept because it’s indispensable for everyday work. That lineage keeps DAC in proportion: it’s not a flaw to eliminate but a deliberately limited tool that the rest of the field was built to complement.

The reference monitor: what actually says no

DAC describes who decides the policy, but something has to enforce it on every access, without exception and without being bypassed. That something is the reference monitor, a concept as old as access control theory. It has to be always invoked, so no access path skips it; tamperproof, so 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’s 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 its ACLs, a debug endpoint that reads files directly, then Sara’s careful permissions mean nothing. Every model in this part of the domain assumes a working reference monitor underneath it. When you later meet the policy enforcement point of the authorization architecture articles, recognize it as the reference monitor promoted to a first-class, network-scale component.

DAC in practice: Linux file permissions

The classic DAC implementation is probably running on the machine you’re reading this on. Every file on a Unix-like system has an owner, a group, and three sets of permission bits, read (r), write (w), and execute (x), for the owner, the group, and everyone else. Run ls -l and you’ll see them:

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

After the leading dash for the file type, the owner sara has rwx; the finance group has r-x, read and execute but no write; and everyone else has ---, nothing. Sara set this, and she can change it whenever she likes with chmod, or hand the file to another owner with chown. That discretion is the whole point. No administrator approved it and no central policy dictated it; Sara decided.

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

Unix also has a special bit, setuid, that makes a program run with the file owner’s privileges rather than the caller’s. It exists for good reasons, since passwd has to edit a file owned by root, but a setuid-root binary with a bug is a direct path to full compromise. It’s also the seed of DAC’s deeper problem: a program acting with privileges the person running it doesn’t directly control, the “confused deputy” we’ll come back to.

The owner, group, and other model is coarse. What if Sara wants to give exactly one person, Daniel, read access without adding him to the product group? The classic bits can’t express that. POSIX ACLs extend the same discretionary model with named entries: setfacl -m u:daniel:r q3.pdf grants Daniel read access directly, and getfacl lists the full set. It’s still pure DAC, the owner extending her own grants to a wider and more precise audience, but it removes the ceiling of the three classic tiers. That’s exactly the command Sara ran.

Capabilities, meanwhile, aren’t a museum piece. A file descriptor passed to a child process is a capability. A pre-signed S3 URL is one: whoever holds the link can fetch the object, with no identity check. An OAuth bearer token, a Kubernetes service account token, a JWT in an Authorization header, a database connection string are all capabilities in the strict sense. 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. Capabilities inherit DAC’s propagation trait in its sharpest form, though: they’re trivial to copy and, as we’ll see, painfully hard to revoke.

DAC in practice: Windows DACLs

Windows makes the ACL model explicit. Every securable object, a file, a registry key, a service, a printer, carries a security descriptor, and inside it a Discretionary Access Control List (DACL), a name that announces the model. The DACL is an ordered list of access control entries (ACEs), each granting or denying a specific right, such as read, write, delete, or 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, collecting granted rights, until it has enough to satisfy the request or runs out and denies it. The object’s owner can always change the DACL, which is precisely what makes it discretionary. Windows adds a lot on top, inheritance from parent containers and a separate SACL for auditing, but the core is a per-object ACL that the owner controls.

Order matters here more than it seems. An ACL isn’t a set; it’s an ordered list, and evaluation stops as soon as the collected 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. That’s why Windows imposes a canonical order, explicit denies first, then explicit allows, then inherited entries, and why mixing deny and allow entries by hand is a classic source of accidental over-permission. The lesson applies widely: any ACL system that supports negative entries makes ordering part of the policy, and an ACL that’s correct as a set can still be wrong as a list. Prefer positive grants to narrow audiences over stacking denies on broad ones.

DAC in practice: databases, the cloud, and every Share button

Once you know what to look for, discretionary control is everywhere. In SQL, GRANT SELECT ON accounts TO daniel is a discretionary grant, and adding WITH GRANT OPTION literally hands Daniel the DAC propagation right: he can now grant SELECT to others, and access spreads outward from the original owner. Cloud object stores began the same way. Amazon S3 object ACLs let an object’s owner grant read access 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 address, you’re the owner adding an entry to that document’s ACL. When you make them an editor and they can share it again, you’ve handed over the grant option. The whole experience of modern collaborative software is a friendly face on discretionary access control.

The trojan horse: DAC’s original sin

DAC is convenient, intuitive, and everywhere, and it has a structural weakness that no amount of careful configuration fixes. It controls access to objects, but it doesn’t 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 public. That’s exactly how the roadmap reached a partner’s inbox.

The classic illustration is the trojan horse. Suppose Sara can read a sensitive file and David, who can’t, gives her a useful-looking tool, a formatter or a linter. When Sara runs it, the program executes with Sara’s rights. Nothing stops it from quietly reading the sensitive file, which Sara is allowed to read, and writing a copy somewhere David controls. Sara never meant to leak anything; the program abused rights she legitimately holds. DAC can’t prevent this, because from the system’s point of view the access was perfectly authorized. It was Sara reading her own file.

This is also called the confused deputy problem, a name Norm Hardy gave it in 1988 after a real case: a compiler that was allowed to write billing records into 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 the user’s behalf. A program with privileges is tricked into using them for someone who lacks them. It’s the fundamental reason high-security environments can’t rely on DAC alone: discretionary permissions travel with the process, not with a policy about the data, so information goes wherever running code carries it. Controlling that flow is what mandatory access control was invented for.

Recall the “assume breach” principle from Zero Trust. Under DAC, one compromised account or one malicious dependency inherits everything that user can reach and can share it onward freely, with no central policy to stop data spreading sideways. That’s why discretionary control on its own is a poor fit for protecting truly sensitive information, and why the other models in this part of the domain exist.

Strengths and weaknesses, honestly

DAC dominates for real reasons and fails for equally real ones. It’s simple and intuitive, because ownership matches how people already think about their things. It’s flexible and immediate, with no ticket, no administrator, and no policy review needed to share a file with a colleague. It’s decentralized, which means it scales socially: millions of people manage their own resources without a bottleneck. And it’s universal, spoken by every operating system, database, and collaboration tool.

On the other side, there’s no central policy, so the organization can’t easily state or enforce a rule like “nobody outside Finance may ever read payroll,” because each owner decides independently. Grants pile up into privilege creep, and because they’re scattered across objects, they’re hard to audit: “who can read this?” is answerable per file, while “everything Daniel can reach” isn’t. It’s exposed to malware and the confused deputy, because running code inherits the user’s rights. And it provides no control over information flow, which leaves the trojan-horse leak invisible. 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 findable in principle, because you edit the object’s list, but in practice grants are scattered across thousands of objects, so fully revoking a person means finding every entry they appear in, everywhere, and no owner-driven system tracks that centrally. Daniel’s leftover permission on q3.pdf is the everyday version of this. With capabilities it’s worse: once you’ve handed out an unforgeable token saying “the holder may read X,” you generally can’t 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 keep a revocation list you check on every use, which quietly turns the capability back into an ACL lookup.

You’ve already met this tension. Revoking a session or an OAuth token is hard for exactly the same reason, because a bearer token is a capability. Seeing revocation as a general weakness of discretionary, possession-based access, rather than a quirk of one system, is one of the most useful things to take from this article. When an auditor asks you to prove that a former contractor can no longer reach anything, an estate built only on DAC can’t answer cleanly, and that gap drives the more centralized models ahead.

Back to the roadmap folder

Look at Sara’s folder again with all of this in mind. Her setup, 750 on the folder plus a POSIX ACL for Daniel on one file, was DAC at its best: clean, immediate, no administrator involved. The forwarded PDF is DAC’s lack of control over information flow. The unanswerable “who has access?” is DAC’s scattered grants, spread across the folder’s mode, individual file ACLs, and group membership. And Daniel’s lingering permission is DAC’s revocation problem.

Now imagine the same folder with a central model on top. Under RBAC, access to /research would come from a role, “Product, roadmap,” that the joiner-mover-leaver process attaches and removes automatically, so Daniel’s departure would remove his access in one place and “who can read this?” would have one authoritative answer. Under MAC, q3.pdf might carry a Confidential label that forbids sending it over an unclassified channel at all, so Daniel couldn’t have emailed it in the first place. DAC did nothing wrong; it did exactly what its owner told it to. But what the owner told it isn’t the same as what the organization needs, and that gap is why the rest of these articles exist. We’ll solve this folder again, better, with each new model.

Where DAC fits among the models

DAC isn’t wrong; it’s a layer. Real 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 has to satisfy every layer that applies, and DAC is almost always the bottom one, the owner-driven baseline, with more centralized models added where the organization needs guarantees that owner discretion can’t give.

Understanding DAC first makes the rest of the family make sense, because each model is partly an answer to something DAC can’t do.

DAC stands alone in one respect: it’s the only model in the family where ordinary end users routinely write policy. Every other model moves that authorship toward administrators, security teams, or formal policy, trading DAC’s immediacy for control, scale, and auditability. That trade runs through every article that follows.

Recap

Discretionary access control is the foundation the rest of authorization is built against. The owner decides: access is set at the owner’s discretion, and the people they grant rights to can often pass them along, the propagation property from the Orange Book. It’s the access control matrix sliced by object, usually implemented as ACLs, while capabilities are the same matrix sliced by subject and reappear as tokens and signed URLs. It runs the world, through Linux permissions and POSIX ACLs, Windows DACLs, SQL GRANT, S3 object ACLs, and every Share button. Its weakness is propagation rather than access: it controls who opens an object but not what happens to the data afterward, hence the trojan horse and the confused deputy. And it’s a layer, not the whole story, with MAC, RBAC, and ABAC adding the central policy, scale, and context it lacks.

Three questions to test yourself

1. A colleague says, “We use ACLs, so we’re not doing DAC.” Explain why that 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 property of DAC makes the leak possible, and which model from later in this part of the domain would prevent it?
3. Your manager wants to answer both “who can read the payroll file?” and “everything Daniel can access” from the same system. Which question 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 and getfacl on Linux, or ls -le on macOS, to add and inspect an entry for a named user. Write down the octal mode for “owner read and write, group read, others none.”
2. Find the propagation right. In a database you can access, or in a cloud IAM console, locate the equivalent of WITH GRANT OPTION, the setting that lets someone you granted access grant it again. Note who in your environment currently holds it, and whether that’s intentional.
3. Audit a sprawl of shares. Pick a shared folder in Google Drive, SharePoint, or a network share. List everyone who has access and how they got it: direct share, group, inheritance, or a re-share. Notice how hard it is to get a complete answer. That difficulty is DAC’s governance weakness, and it’s the problem RBAC sets out to tame.