Discretionary Access Control (DAC)

Discretionary Access Control (DAC) is one of the most fundamental concepts in computer security, built on an idea we instinctively understand: ownership. Just as you control who enters your home, DAC allows the owner of a digital resource—be it a file, a photo, or a folder—to decide who can access it. This intuitive model forms the security backbone of the operating systems we use daily. However, its apparent simplicity masks a world of deep complexity, subtle vulnerabilities, and intricate technical challenges. The very freedom that DAC provides to owners also creates opportunities for error and exploitation.

This article delves into the dual nature of Discretionary Access Control, exploring both its foundational strengths and its inherent weaknesses. We will dissect the puzzles that arise from seemingly simple actions like sharing and unsharing, revealing the gap between a user's intention and the system's actual behavior. By the end, you will understand not just what DAC is, but why it remains a critical, albeit incomplete, piece of the larger security puzzle.

The journey begins in the Principles and Mechanisms chapter, where we will formalize the concept of DAC, introducing core components like Access Control Lists (ACLs) and exploring the critical challenges of delegation, revocation, and the infamous Time-of-Check to Time-of-Use problem. Following this, the Applications and Interdisciplinary Connections chapter will bridge theory and practice. We will examine how DAC plays out in real-world scenarios—from file system vulnerabilities and ransomware attacks to the sophisticated, layered security models of modern cloud platforms—illustrating how its principles are adapted, augmented, and even transcended to meet the demands of a distributed, encrypted world.

At its heart, Discretionary Access Control (DAC) is the most intuitive security model imaginable. It’s the digital equivalent of owning a house. You own it, so you hold the keys. You decide who gets a copy of the key, who can visit, and who can borrow your lawnmower. The "discretion" is yours. This simple, powerful idea is the foundation of security on most operating systems we use every day, from the files on your laptop to the photos on your phone. But as we peel back the layers, we'll find that this simple concept of ownership leads to a world of fascinating complexity, subtle traps, and elegant solutions. It's a journey that reveals the very nature of information, identity, and trust in a digital world.

Let's formalize our house analogy. In an operating system, the things we want to protect are called objects​—files, directories, or even specific system settings. The entities that want to access them are called subjects​—users like you, or the programs running on your behalf. The system needs a way to remember your decisions. This is typically done with an Access Control List (ACL).

Think of an ACL as a guest list posted on the front door of your house (the object). It lists each subject and the permissions they have: "Alice can read," "Bob can read and write," "Charlie has no entry" (and is thus denied). As the owner, you have the discretion to add or remove names from this list.

This is DAC in its purest form. It’s simple and powerful. Yet, this very simplicity is the seed of its most common problem: human error. Imagine a system administrator, in a moment of haste, adds the entire "Users" group to the ACL for a sensitive system configuration file, giving them all write access. A clever user could then modify that configuration to grant themselves higher privileges. This isn't a flaw in the model itself, but a direct consequence of its discretionary nature. If the owner has the freedom to make rules, they also have the freedom to make mistakes.

The plot thickens when we move beyond simple access. What if, instead of just lending a key to your friend, you also give them a key-copying machine? In DAC, this is called delegation​: granting a subject the permission to grant permissions to others. Suddenly, you are not just managing your direct friends, but a whole branching web of trust.

This creates a profound challenge for what should be a simple action: revocation​. Taking your key back from your direct friend is easy. But how do you reclaim all the copies they made and distributed?

We can visualize this as a graph, where users are nodes and permissions are directed edges. When one user grants a permission to another, an edge is drawn. If the grant includes delegation rights, that edge has a special quality. Now, if the original owner revokes a foundational grant, what should happen? Logic dictates that any permissions that depended on that grant must also vanish. This is called cascading revocation​. If you take away the key-copying machine from your friend, any keys they made with it should, in a perfectly logical world, become invalid. Otherwise, we are left with orphaned grants​—permissions that exist but have no valid chain of authority back to the owner.

In practice, many simple DAC systems don't handle this well. If Alice grants a right to Bob, and Bob passes it to Carol, Alice revoking Bob's right might not affect Carol at all. Carol's access lingers. The owner's absolute control begins to fray the moment permissions are delegated. This reveals a fundamental trade-off of DAC: high owner autonomy comes at the cost of diminished end-to-end control.

Revocation is even more complex than just updating a list. An operating system is not a static set of rules; it's a dynamic environment with active processes and states. This leads to one of the most subtle and important concepts in security: the gap between Time-of-Check and Time-of-Use (TOCTOU).

Imagine you lend a book to Bob. The "check" happens when you give him the book. Later, you call Bob and tell him he's no longer allowed to read your books (revocation). But the book is still sitting on his nightstand. The "use" (reading) can continue until he actually returns the book.

In an operating system, when a program "opens" a file, the system checks the ACL. If access is permitted, the kernel grants the program a file descriptor​—a handle that is conceptually like having the physical book in hand. The program then uses this descriptor for all subsequent read and write operations. If the file's owner changes the ACL to revoke access after the file has been opened, it's too late for that running program. The kernel, for efficiency, doesn't re-check the ACL on every single read or write. The already-granted access lingers like a ghost in the machine until the file descriptor is closed.

This same principle applies to user credentials. If a user is removed from a group in the system's central database, any programs they are currently running don't magically know this. Those programs were launched with a snapshot of the user's credentials at that time, including their group memberships. They will retain the privileges of that group until the processes are terminated and new ones are started.

How do we solve this? The most robust solutions involve adding a layer of indirection​. Instead of a file descriptor being a direct ticket to access, it could point to a "lease" or a "revocation object" that is checked on every use. When the owner revokes permission, they just invalidate that central object, and all handles pointing to it instantly fail. Another powerful strategy is to focus on the object, not the subject. Rather than trying to update the credentials of every running process, it's often more effective to simply change the lock on the resource itself (e.g., by changing the file's group ownership to a new "shadow group").

To truly appreciate DAC, we must look at how it's implemented in the real world, like in Unix-style systems. Here, the beautiful abstractions meet messy reality.

First, what is a "file"? Is it its name, like /home/alice/report.txt? No. In Unix, a file is an inode​, a data structure on the disk that holds the file's metadata and content. A name is just a pointer in a directory that leads to an inode. Crucially, a single inode can have multiple names, known as hard links​. This poses a critical question: where does the ACL live? If it lived on the name, you could revoke access to report.txt, but a user could still access the file via its other name, final_report.txt. This would defeat the purpose of revocation. Therefore, the ACL must be attached to the true object: the inode. Permissions are about the thing​, not the name of the thing​.

Second, when you create a new file, where do its permissions come from? They are inherited from the parent directory. Directories can have a default ACL that acts as a template for all new objects created within them. This is a powerful feature, but also another trap for the unwary. If you want to permanently revoke a user's access to a project, it's not enough to remove them from the ACLs of all existing files. You must also remove them from the default ACL of the project directory, or they will regain access the moment a new file is created.

Finally, the evaluation itself is a precise algorithm. When a user tries to access a file, the system follows a strict order of operations: first, it checks if the user is the owner. If so, owner permissions apply. If not, it checks for a specific named-user entry in the ACL. If not, it checks if any of the user's groups match a group entry. Finally, if no other rule matches, the "other" permissions apply. To add another layer of control, POSIX ACLs feature a mask entry, which defines the maximum possible permissions for all named users and groups, acting as a global throttle that the owner can adjust without editing every single entry.

For all its intuitive appeal, DAC has its limits. Its very nature—individual owners making individual decisions—creates two major challenges as systems grow.

The first is scalability​. Imagine being a system administrator for a company with 10,000 employees. If access is managed user-by-user, file-by-file, the task is impossible. Revoking access for a single departing employee could involve editing thousands of ACLs. This administrative nightmare is precisely why Role-Based Access Control (RBAC) was developed. In RBAC, permissions are granted to roles (e.g., "Engineer," "Accountant"), and users are assigned to roles. To revoke an engineer's access, you simply remove them from the "Engineer" role—a single action that propagates everywhere.

The second challenge is absolute security​. What if you have data so sensitive that you need a guarantee it won't be leaked, even by accident? In DAC, the owner of a "Top Secret" file could mistakenly grant read access to a "Public" user. This is where Mandatory Access Control (MAC) comes in. In a MAC system, objects and subjects are given system-wide security labels (e.g., Confidential, Secret, Top Secret). The system enforces a simple, non-negotiable rule: a subject can only read an object if its security level is the same or higher. A "Confidential" user simply cannot read a "Secret" file, regardless of what the file's ACL says. The mandatory policy always takes precedence over the discretionary one.

Discretionary Access Control remains the bedrock of modern security. It is the language of ownership and permission that we all understand. But its journey from a simple idea to a real-world implementation reveals deep truths about state, identity, and trust. It shows us that to build secure systems, we must understand not only the rules we set, but also the subtle, complex, and beautiful machinery that brings those rules to life.

The idea of Discretionary Access Control, where the owner of an object gets to decide who can play with it, feels as natural as deciding who to invite into your home. It’s simple, intuitive, and it forms the very bedrock of security in countless systems we use every day. But as with any profound and simple idea in physics or computer science, the real fun begins when we push it, test its limits, and see where it leads us. This journey will take us from the familiar world of our personal files into the heart of ransomware attacks, the global web of social networks, and the cryptographic core of modern cloud storage. We will see that while DAC is a beautiful and indispensable starting point, its true power in the modern world is realized in a graceful dance with other security principles.

Every time you right-click a file on your computer and set its permissions, you are the discretionary owner in a small DAC universe. You decide who in your "world" (the other user accounts on the machine) can read, write, or execute your creation. This is DAC in its purest form. But this simple picture immediately raises a subtle and profound question: when you grant access to a program​, do you trust what it will do with that access?

Imagine a research lab where a sensitive dataset must be readable by all researchers for analysis, but must never leave the lab's network. The lab director, acting as the owner, can use DAC (perhaps through Access Control Lists, or ACLs) to grant read permission to the 'researchers' group. So far, so good. But what stops a researcher's perfectly legitimate data analysis program—which has been granted read access—from also being tricked into quietly copying that data to an external server? Nothing in the DAC model does. DAC governs whether a subject can open the door to an object; it has no say in what they do once inside. This is the classic "confused deputy" problem, where a program with legitimate authority is duped into misusing it. To solve this, one must turn to a stricter parent: Mandatory Access Control (MAC). A MAC policy could state that a process labeled as 'internal_analysis' can read data labeled 'sensitive', but is forbidden from writing to any object labeled 'external_network'. Here, DAC manages the basic access, while MAC controls the information flow—a beautiful example of policy composition.

The reliance on a subject's identity presents another, more dramatic challenge. In UNIX-like systems, there is a "superuser," root, who is, in essence, the owner of everything. root can bypass all DAC checks. What if a normal user could temporarily become root? This is precisely what setuid root programs do. They are helper utilities that any user can run, but they execute with the full power of the superuser. If an attacker can replace such a helper with a malicious Trojan horse, they have effectively stolen the keys to the entire kingdom. The DAC model, with its neat divisions of ownership, collapses entirely. The Trojan, running as root, can read the password file, install surveillance software, and erase any trace of its presence. This isn't a theoretical flaw; it's a classic vulnerability pattern. The modern response is a lesson in the principle of least privilege. Instead of granting the monolithic power of root, operating systems can grant fine-grained capabilities​. A backup program might be granted just CAP_DAC_READ_SEARCH, the specific power to bypass read permissions on any file—exactly what it needs to do its job, but nothing more. It cannot load kernel modules or reconfigure the network. The blast radius of a compromise is dramatically reduced, showing an evolution in thinking from coarse user identities to fine-grained process capabilities.

Granting permission is easy; taking it back is one of the hardest problems in computer security. When you "unshare" a photo with a friend on a social network, you expect their access to vanish instantly. But what if they had already re-shared it with others?

This scenario maps perfectly to DAC with a 'grant' right. Let's say you ($A$) share a photo with your friend ($B$), giving them permission to re-share it. $B$ shares it with $C$. Later, you also share it directly with $C$. Now, you have a falling out with $B$ and revoke their access. What should happen? Should $C$ lose access? What about $D$, who only got the photo from $B$?

There are different philosophies. Local-only revocation would only cut off $B$, leaving $C$ and $D$ with access—which might not be what you intended. Naive cascading revocation would cut off $B$, and everyone $B$ ever shared with, including $C$—but this ignores the fact that you shared it with $C$ directly! The most intuitive approach is selective cascading revocation​: the system traces the paths of authorization. $D$ loses access because their only path was through $B$. But $C$ keeps access because they still have a valid path directly from you, the owner. This logic, which respects alternate authorization paths, is often what users expect and is a key challenge in designing any sharing system.

This logical puzzle becomes a thorny technical problem inside the operating system. Imagine a piece of ransomware begins encrypting your files. You or a security system detects this and immediately revokes the program's write permissions. Problem solved? Not with standard DAC. Most operating systems perform the DAC check only at the moment a file is opened (the open() system call). If the check passes, the process is given a "ticket" called a file descriptor. All subsequent writes using that ticket are honored, even if the file's permissions on disk are changed. The revocation comes too late; the ransomware can finish encrypting the file it already has open. This is a "time-of-check to time-of-use" (TOCTOU) vulnerability. To stop the attack cold, you need a system that checks permission on every single write​—a principle called "complete mediation," which is a hallmark of MAC systems. This starkly illustrates how the dynamics of revocation reveal deep differences between access control models. This challenge is amplified in systems with layers of caching, where stale permissions might persist, creating a window of vulnerability even for new access attempts until the cache expires or is explicitly flushed.

Far from being an obsolete relic, DAC is a vital component in the most sophisticated systems today, often acting as one instrument in a larger orchestra. We see this in the way policies are composed. Consider a lab that needs to enforce a data embargo. Day-to-day access can be managed flexibly with DAC and Role-Based Access Control (RBAC). But when the embargo date arrives, a non-negotiable, system-wide rule must take effect. This is a job for MAC. By defining an "embargoed" security label that is applied to the data at a specific time, the system can automatically and infallibly override all discretionary grants. Access is now permitted only if the user has the 'embargo_clearance' role (RBAC), the owner has shared the file (DAC), and the system's mandatory policy permits it (MAC). This elegant layering combines the flexibility of DAC with the rigor of MAC.

The plot thickens when we enter the world of distributed systems. Imagine a peer-to-peer storage network where file permissions (ACLs) are replicated across many nodes. If an owner on one node revokes access, how long does it take for that change to reach all the other nodes? If the system uses "eventual consistency" to maximize availability, there will be a delay. During this window, a user could query a node that hasn't yet received the update and be granted access, violating the owner's intent. To guarantee immediate revocation safety, the system must use "strong consistency." This means the revocation operation must wait until it is confirmed across the necessary number of nodes before completing. The consequence? If a network partition occurs, the system might have to deny access to everyone to avoid making a wrong decision. This reveals a profound link between security and the fundamental trade-offs of distributed computing, famously captured in the CAP Theorem: you can't always have perfect Consistency (safety) and Availability at the same time.

The very notion of a "user" as the primary actor is also evolving. In a classic multi-user OS, DAC was about separating Alice's files from Bob's. In a modern mobile phone or a cloud server, the primary actors are isolated applications​. Each app lives in its own sandboxed universe, governed by a strict MAC policy that dictates what system resources it can touch. This is a paradigm shift away from the user-driven DAC of a desktop OS, but the conceptual lineage is clear. The goal is still to separate principals and protect their objects, but the principal is now an app, and the protection model has shifted from discretionary to mandatory to protect the user from their own applications.

Finally, what if we could build a better time machine for revocation? What if we could forcefully invalidate the "ghosts of permissions past"—those file descriptors that linger after a DAC permission has been changed? A wonderfully clever approach combines access control with cryptography. Imagine each file is encrypted with its own unique key, $K$. When a process opens the file, its file descriptor is bound not just to the file, but to the key $K$. Now, to revoke access, the system doesn't just change a permission bit. It generates a brand-new key, $K'$, re-encrypts the entire file with $K'$, and throws away $K$. Any process holding an old file descriptor is now holding a key to the wrong lock. Its access is rendered completely useless. Of course, the system must also be careful to purge any cached plaintext copies of the data from memory. This cryptographic revocation is a powerful technique for enforcing immediate and complete revocation in complex multi-tenant environments, such as cloud servers with shared block storage, effectively slaying one of DAC's oldest dragons.

Discretionary Access Control, in its elegant simplicity, is the question that sets us on a journey. In trying to solve the puzzles it presents—the confused deputy, the superuser, the unstoppable ransomware, the reshard photo—we are led to a deeper understanding of security. We discover the necessity of mandatory controls, the subtleties of policy composition, the trade-offs of distributed state, and the ultimate power of cryptography. DAC is not the final answer, but it is, and remains, the perfect beginning.