Dac and Mac
You set up dac and mac by pairing owner rules with central system labels. Resource owners control local file permissions, while system rules enforce strict clearance checks. Most teams start with owner rules because they are easy to manage. Over time, users share broad roles to get their daily work done fast. When permissions grow too wide, one bad command can harm critical production data. How dac and mac work in system architecture Discretionary access control, or DAC, puts the resource own
Mac: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up dac and mac by pairing owner rules with central system labels. Resource owners control local file permissions, while system rules enforce strict clearance checks. Most teams start with owner rules because they are easy to manage. Over time, users share broad roles to get their daily work done fast. When permissions grow too wide, one bad command can harm critical production data.
How dac and mac work in system architecture
Discretionary access control, or DAC, puts the resource owner in charge of permissions. The person who creates a file or table decides who can read it. They can also grant write or run rights to other local users. Operating systems and databases check a list of users attached to each object. If your user name is on that list, the system lets you in. Owners can pass these rights to others at any time without asking admins.
Mandatory access control, or MAC, takes that choice away from individual resource owners. A central admin sets strict labels on all users and all data objects. Each user gets a clearance level and a specific group tag for work. Each file or database table gets a matching sensitivity label from the admin. When a user tries to read a file, the system checks both labels. Both the clearance level and the group tag must match the file label. Even the person who made the file cannot change or share these rights.
Where native permission models fall short in daily work
Both models do a good job of deciding who can log in. DAC makes team sharing fast and simple for daily project work. MAC stops users from sharing secret files with the wrong people by mistake. Together, they set strong walls around files, tables, and hosts at rest.
Still, both models leave a big gap open during live user sessions. Native rules only check identity and labels at the start of a task. Once a user passes that check, the system trusts every action they take. An engineer with valid read rights can pull a whole table of emails. They can also see raw phone numbers, card numbers, and national IDs. An admin with write rights can drop a critical table by mistake. Native DAC and MAC rules do not inspect live queries or shell commands. They cannot mask sensitive fields in results by rewriting matched fields in flight. They also cannot pause a risky command to ask a peer for approval.
Mac: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to combine owner rules with central guardrails
To keep systems safe, teams should keep base roles narrow and clear. Start by using central rules to separate prod data from test data. Give users only the base roles they need for normal daily reading. Avoid giving out broad owner rights on shared production databases or servers. Next, add controls that watch what commands and queries do in flight. This step catches bad commands and rewrites sensitive data before it leaves.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the main difference between DAC and MAC?
In DAC, the data owner decides who gets permission to read or write. In MAC, a central system rule checks user clearance labels against data labels.
Can a system run DAC and MAC at the same time?
Yes, many systems evaluate both models at the same time for each request. A user must pass both the central label check and the owner list.
Why do teams need more than static DAC and MAC rules?
Static rules only check who can log in or open a whole file. They do not inspect live queries, block bad commands, or mask card numbers.