不吃章鱼烧上周同事跑过来问我一件事：部门有个共享目录，研发组要读写，但审计那边的人只需要定期瞄一眼，不能让他们写。他问我打算怎么处理，我下意识回了一句"那不就 chmod 777 呗"。这四个数字从嘴里蹦出来的时候，我自己都愣了一下，这大概是我见过最经典、也最危险的"省事方案"——目录一旦放开，整个部门都能改，审计那边想不被影响都难，纯粹靠自觉做事。其实这种场景在 Linux 权限管理里早就有正经解法，就是标题里这个 ACL（Access Control List，访问控制列表），对应 Linux 上的 POSIX ACL 实现。它解决的核心问题，说白了就是一句话：传统权限只认三种身份，而现实环境里你需要的是按人头、按小组单独发权限。
这篇文章我不打算写成 man 手册翻译，而是按我实际用下来的经验讲清楚三件事：ACL 到底解决了传统权限的什么痛点、setfacl/getfacl 的正确姿势、以及我在真实部署里踩过但文档里往往不写的坑。适合正在给 Linux 服务器做文件管控、或者被共享目录权限问题折腾过的人看，看完能直接抄作业。
1. 传统权限模型的三位困局：755 和 644 到底卡在哪
1.1 ugo 三身份：一个只能回答"三种问题"的模型
Linux 传统的文件权限模型，基础就三个身份：属主（user）、属组（group）、其他（other），加上三组权限位 rwx。这套模型从早期 Unix 一路传下来，胜在简单可靠，但简单是有代价的——它把"谁可以访问这个文件"这个问题硬生生压缩成了三种答案。
你去看一个文件的权限位，本质就是回答三个问题：
- 我是文件的属主吗？如果是，看属主那一组权限位。
- 我不是属主，但我属于文件的属组吗？如果是，看属组那一组权限位。
- 上面两个都不是？那就归到"其他"，看最后一组权限位。
听起来很顺，问题是第三个答案"其他"是个筐，什么人都能往里装。假设服务器上有一百个普通用户，其中只有一个人需要读某个文件，传统模型下你能怎么办？要么把那个人加入文件属组，要么给"其他"位加上读权限。前者会让他顺便获得整个组的所有权限，后者等于把文件读权限开放给了一百个人。无论选哪个，授权范围都比你原本想要的大得多。
这个模型还有一个隐含的尴尬：它不关心"具体是谁"。永远只有三种桶，人和组都得想办法往三个桶里塞。当一台机器上的人一多、角色一杂，这个模型就开始到处漏风。
1.2 现实中的细粒度需求从哪里冒出来
我整理了一下实际工作中最容易碰到"传统权限搞不定"的场景，基本是这几类：
- 跨部门协作：目录属于研发中心，但财务部的人每个月底要读一份报表。你既不想把财务的人加进研发组，又不想把目录放给整个研发中心以外的所有人。
- 外包与临时人员：外包运维需要读服务日志，可能还要往某个临时目录写文件，但你不能给他所在组的标准权限，更不能让他拿到服务器上的其他敏感目录。
- 共享目录多租户：一个公共空间里有 A、B 两个项目组，大家都在这台机器上，两个组之间不能互写，却又要共享同一个父目录结构。
- Web 目录与部署用户：网站文件属于 www-data 组，但某位前端同学需要更新静态资源，又不能让整个 www-data 组都有写权限。
这些场景里，你要是硬用 chmod，最后几乎都会被逼到两个方向：要么 chmod 777 把权限彻底放开，要么不断把人拉进组、拉出组，组权限越滚越大，最后谁有哪些权限，谁也说不清。
chmod 777 的危害不用我多说：文件被篡改是小事，更常见的是业务数据被误删、恶意用户拿到敏感文件后，你连排查日志都判断不了是谁干的，因为在权限层面压根就没有"谁"这个概念。真正问题不是系统管理员不知道 777 不好，而是传统模型没给选项，把人逼到了那一步。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ACL 为什么能补上缺口：一张名单解决三种身份之外的一切
2.1 ACL 的本质：把受控对象从"身份"变成"条目"
ACL 的思路其实很朴素：既然"三种桶"不够用，那我直接允许你在文件上挂一张名单，名单里可以写具体用户、具体用户组，并为每一个条目分别指定权限。传统模型的 ugo 三种身份，在 ACL 里变成了六类基础条目：
| 条目类型 | 含义 |
|---|---|
| user:: | 文件属主的权限，对应传统属主位 |
| user:用户名: | 特定用户的权限，传统模型里没有 |
| group:: | 文件属组的权限，对应传统属组位 |
| group:组名: | 特定用户组的权限，传统模型里没有 |
| mask:: | 掩码，限制所有具名条目的有效权限上限 |
| other:: | 其他用户的权限，对应传统其他位 |
所以我说 ACL 的本质，是把"身份"变成了"条目"。门卫时代只认三类人——业主、访客、陌生人；ACL 时代就是一张门禁名单，谁拿到什么权限，全部按名单来，名单上没有的人，一律按 other 对待。这个概念大家都能秒懂，但真正用起来有几个细节必须说清楚。
2.2 访问 ACL 与默认 ACL：一个管现在，一个管未来
ACL 分两大类。第一类是访问 ACL（access ACL），直接作用于文件或目录本身，决定"现在谁能对这个文件干什么"。我们平时用 setfacl 给某个用户授权，改的就是访问 ACL。
第二类是默认 ACL（default ACL），这个概念非常重要，但也是新手最容易忽略的。默认 ACL 只能设置在目录上，它本身并不直接限制目录当前的访问，它决定的是"该目录下以后新建出来的文件和子目录，会自动带上哪些权限"。
举个例子：你在 /srv/data 上设置了一个默认 ACL，让 user:zhangsan 拥有 r-x 权限。之后无论谁在这个目录下新建文件，只要这个新文件是通过正常的 open/create 流程创建的，它都会自动继承一段 ACL，把 zhangsan 的 r-x 带过去。没有默认 ACL 的时候，新建文件只根据 umask 生成权限位，完全不记得"这里有个外人需要访问"这件事。
所以如果你想为一个目录体系做长期的权限