3. 自主访问控制（DAC）
3.1 什么是 DAC？
自主访问控制，英文叫 Discretionary Access Control，简称 DAC。说白了，就是“谁创建，谁做主”。资源的主人（通常是创建它的用户）可以自己决定谁能访问、能干嘛。
你想想看，你在 Linux 里创建一个文件，默认就属于你。你想让别的用户读、写、执行，直接用 chmod 改个权限就行。这就是最典型的 DAC 模型。我记得刚入行时，前辈就跟我说：“Unix 的权限模型，就是 DAC 的活教材。”
大多数商业操作系统，比如 Windows、macOS、Linux，默认都是 DAC。为什么？因为它简单、灵活，用户自己能控制。我在项目中遇到过很多团队，内部开发环境全靠 DAC 管理权限，大部分时候跑得挺好。
🔍 DAC 的核心概念：每个客体（文件、目录、设备）都有一个所有者，所有者可以任意将权限授予其他主体（用户、进程）。
3.2 实现方式
DAC 主要有两种实现方式，咱们一个一个看。
3.2.1 基于权限位的 DAC
最经典的实现就是 Unix/Linux 的 9 位权限位。你肯定见过这个：
rwxr-xr-- 1 user staff 1024 Apr 10 12:00 myfile.txt
这 9 位分三组：所有者（user）、所属组（group）、其他人（other）。每组三个权限：读（r=4）、写（w=2）、执行（x=1）。
我常用的命令就两个：
chmod 644 file– 所有者读写，其他人只读chmod 700 dir– 所有者全部权限，其他人无权
我曾经踩过一个坑：把包含数据库密码的配置文件设成 chmod 777，结果其他用户也能看。那次之后我养成了习惯：凡是敏感文件，默认只给 600 或 640。
3.2.2 基于 ACL 的 DAC
权限位只能控制三个主体（自己、组、其他人），太粗糙了。ACL（访问控制列表）可以精确到每个用户、每个组。Linux 下用 setfacl 和 getfacl 管理：
# 给用户 alice 读权限
setfacl -m u:alice:r file.txt
# 查看 ACL
getfacl file.txt
Windows 的 NTFS 权限也是 DAC 的一种，它叫“安全描述符”。你可以给每个特定用户分配“读取”“修改”“完全控制”等权限。那个界面我至今觉得不够直观，但功能确实强大。
| 实现方式 | 粒度 | 典型平台 | 管理成本 |
|---|---|---|---|
| 权限位 (Permission Bits) | 粗（所有者/组/其他） | Linux / Unix | 低 |
| ACL (Access Control List) | 细（每个用户、每个组） | Linux ext4 / Windows NTFS | 中 |
| Windows 安全描述符 | 细（可继承、可审计） | Windows | 较高 |
3.3 优缺点分析
DAC 好上手，但也有硬伤。我一个个说。
✅ 优点
- 灵活：所有者可以随意授权，不用走审批流程
- 易用：用户自己就能明白，不需要管理员介入
- 性能好：权限检查直接在文件系统层面完成，很快
⚠️ 缺点
- 不安全：如果一个恶意程序拿到了你的权限，它可以访问你的所有文件，因为所有文件都属于你
- 难以审计：权限分散在大量用户手中，谁授权给了谁很难追踪
- 木马传播风险：用户可能无意中给恶意软件可执行权限，导致横向移动
举个真实的例子。我曾经为一家金融公司做内部系统评估，发现测试服务器上某个 Windows 共享文件夹所有人是 Everyone，权限是“完全控制”。原因是运维偷懒，直接设了 Everyone 方便调试。结果某天一个实习生误删了数据库备份…… 这就是 DAC 的典型翻车现场——太自由，反而容易失控。
所以很多高安全场景（比如军工、银行核心）会改用 MAC（强制访问控制）。但日常开发、企业内部，DAC 仍然是主力。
3.4 DAC 核心逻辑图
下面这张图帮你理清 DAC 的整体结构：