自主访问控制（DAC）：原理、模型与实战

聊到访问控制，我第一个想跟你聊的就是 DAC。为什么？因为它是我们日常接触最多的模型——你电脑上的文件权限、Linux 系统里的 chmod，说白了都是 DAC 的体现。我刚开始做安全那会儿，总觉得 DAC 太简单，没什么好学的。后来在项目里栽过跟头，才明白越是基础的东西，越容易出大问题。

DAC 的核心思想：资源归谁，谁说了算

自主访问控制，英文叫 Discretionary Access Control。名字挺长，但意思很直白：资源的拥有者可以自主决定谁能访问它。你创建了一个文件，你就是它的主人。你想让谁读、让谁写、让谁执行，你说了算。

举个例子。你在 Linux 里 touch 了一个文件，默认只有你能读写。如果你想让你同事也能看，一个 chmod o+r 就搞定了。这就是 DAC——权限的分配权在资源所有者手里。

Linux rwx 权限模型：三组九位的秘密

说到 DAC，Linux 的 rwx 模型是绕不开的。我见过不少开发同学，用了好几年 Linux，对 rwx 的理解还停留在「r 是读，w 是写，x 是执行」。嗯，这没错，但远远不够。

rwx 权限分三组，每组三位：

• 第一组（owner）：文件所有者的权限
• 第二组（group）：文件所属组的权限
• 第三组（others）：其他人的权限

每组三位分别对应 r（读）、w（写）、x（执行）。用数字表示就是 4、2、1。你肯定见过 chmod 755 这种写法——7 就是 4+2+1，表示读写执行全开；5 就是 4+1，表示读和执行。

# 查看文件权限
$ ls -l myfile.txt
-rw-r--r-- 1 alice devops 1024 Jan 15 10:30 myfile.txt

# 解读：所有者 alice 有读写（rw-），组 devops 有读（r--），其他人有读（r--）

# 修改权限：给所有者加执行权限
$ chmod u+x myfile.txt

# 修改权限：设置所有人可读可写
$ chmod 666 myfile.txt

这里有个坑，我提醒你一下。目录的 x 权限和文件的 x 权限含义完全不同。文件的 x 是执行，目录的 x 是进入。我曾经遇到一个同事，把某个目录的 x 权限去掉了，结果所有人都进不去，包括他自己。嗯，那场面挺尴尬的。

ACL 列表：当 rwx 不够用的时候

rwx 模型有个硬伤——它只能控制三组人：所有者、所属组、其他人。但实际场景里，你可能需要给多个用户或组设置不同的权限。比如，一个项目文件，你希望 Alice 能读写，Bob 只能读，而 Charlie 什么都干不了。rwx 搞不定这个。

这时候就需要 ACL（访问控制列表）出场了。ACL 说白了就是给 rwx 模型打了个补丁，让你能针对单个用户或组设置权限。

# 查看文件的 ACL
$ getfacl myproject.txt
# file: myproject.txt
# owner: alice
# group: devops
user::rw-
user:bob:r--
group::r--
mask::r--
other::---

# 给 Bob 添加读权限
$ setfacl -m u:bob:r myproject.txt

# 给 devops 组添加读写权限
$ setfacl -m g:devops:rw myproject.txt

# 移除 Bob 的权限
$ setfacl -x u:bob myproject.txt

ACL 的好处是灵活，但坏处是容易乱。我在一个项目里见过一个文件，ACL 列表里挂了十几个用户和组，维护起来简直是噩梦。所以我的建议是：能用 rwx 解决的问题，别用 ACL。ACL 是最后的手段，不是首选。

DAC 的优缺点：一把双刃剑

DAC 最大的优点就是灵活。资源所有者可以按需分配权限，不需要管理员介入。这在小型团队或个人使用场景下非常高效。你想想看，如果你每次改个文件权限都要找管理员审批，那得多耽误事。

但 DAC 的缺点同样明显：

优点	缺点
灵活，资源所有者自主控制	权限可能被滥用或误传
实现简单，Linux/Windows 原生支持	无法强制实施全局安全策略
适合小型团队或个人使用	权限管理分散，审计困难
用户学习成本低	容易产生权限扩散（权限越给越多）

我遇到过最典型的 DAC 翻车案例是这样的：一个开发同学为了省事，把自己服务器上的一个脚本设成了 777（所有人可读写执行）。结果被攻击者利用，直接拿到了服务器的执行权限。你说这是 DAC 的问题吗？不，是人的问题。但 DAC 给了人犯错的空间。

DAC 知识体系总览

下面这张图帮你梳理了 DAC 的核心脉络。你可以看到，DAC 从原理出发，衍生出 rwx 模型和 ACL 两种实现方式，各有各的适用场景和风险点。

实战建议：DAC 的正确打开方式

说了这么多，最后给你几条实战建议：

1. 权限最小化原则。给用户刚刚好的权限，不多给。能只读就别给写，能只写就别给执行。我见过太多因为「方便」而给 777 的案例，最后都成了安全漏洞。
2. 定期审计权限。用 find / -perm 777 这种命令扫一遍，看看哪些文件权限过宽。我一般每个月扫一次，发现问题立刻整改。
3. ACL 用完后及时清理。ACL 条目多了就是灾难。每次添加 ACL 时，想清楚这个权限是不是真的需要，用完就删掉。
4. 别把 DAC 当万能药。DAC 适合个人和小团队。如果你的组织有严格的合规要求（比如等保、GDPR），那 DAC 就不够用了。后面我们会聊到 MAC 和 RBAC，那才是企业级的选择。