Linux ACL权限管理实战：从chmod 777到精细授权

上周同事跑过来问我一件事：部门有个共享目录，研发组要读写，但审计那边的人只需要定期瞄一眼，不能让他们写。他问我打算怎么处理，我下意识回了一句"那不就 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 不好，而是传统模型没给选项，把人逼到了那一步。

2. ACL 为什么能补上缺口：一张名单解决三种身份之外的一切

2.1 ACL 的本质：把受控对象从"身份"变成"条目"

ACL 的思路其实很朴素：既然"三种桶"不够用，那我直接允许你在文件上挂一张名单，名单里可以写具体用户、具体用户组，并为每一个条目分别指定权限。传统模型的 ugo 三种身份，在 ACL 里变成了六类基础条目：

所以我说 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 生成权限位，完全不记得"这里有个外人需要访问"这件事。

所以如果你想为一个目录体系做长期的权限规划，光设置当前权限是不够的，还要把默认 ACL 一并设好，否则过几天同事新建文件，权限全部回到传统模型的老路上去。

2.3 mask 是闸门：所有具名条目的"有效权限"都被它限制

mask 是 ACL 里最容易让人困惑的一个字段，但理解了它，你基本就掌握了 ACL 的一半。

mask 表示"所有具名条目可以拥有的最大有效权限"。它只影响具名用户（user:name）、具名组（group:name）以及 group:: 这个组条目，不影响文件属主 user:: 和 other::。什么时候它会出现？只要你往一个文件上添加了任意一条具名用户或具名组条目，系统就会自动插入一个 mask 条目，初始值通常是当前所有相关条目的权限并集。

mask 为什么会存在？因为它给了你一个新的控制维度：你可以单独收紧"所有人能拿到的上限"，而不用逐条去改每个具名条目。比如你给十个用户分别设了 rw-，想临时让其中所有人都不许写，传统做法是逐条改成 r--，但有了 mask，直接把 mask 改成 r--，十个用户的有效权限全部降级为只读。getfacl 输出里会看到 #effective: 标记，就是 mask 生效后的真实权限。

但这条"闸门"也带来了很多问题，下文我会专门讲我踩到的坑。

3. setfacl 与 getfacl 实操：从授权到验证的完整链路

3.1 开始前先确认两件事：命令装没装、文件系统支不支持

在 Ubuntu/Debian 上，setfacl 和 getfacl 属于 acl 包，默认不一定安装。我遇到过好几台新机器上敲 setfacl 直接 command not found 的情况，所以第一步先确认：

bash复制command -v setfacl getfacl
# 如果没有输出，用包管理器安装
sudo apt-get install acl        # Debian/Ubuntu
sudo dnf install acl            # RHEL/CentOS 8+ / Fedora
sudo yum install acl            # CentOS 7 及更早的 RHEL 系

第二个前提是文件系统要支持 POSIX ACL。主流文件系统 ext4、xfs、btrfs 基本都默认支持，但以下两种情况要留意：

• 挂载时如果带了 noacl 参数，或者极老的内核，ACL 功能会被禁用；
• vfat、exFAT、ntfs-3g 这类文件系统，本身不支持 POSIX ACL，别指望在这上面用。

检查挂载参数的快捷方式：

bash复制findmnt /data
# 或者
mount | grep /data

输出里只要没有 noacl 字样，一般就是支持的。如果确认不支持但文件系统本身支持，可以重新挂载启用：

bash复制sudo mount -o remount,acl /data

现代主流发行版的内核基本默认开启了 CONFIG_FS_POSIX_ACL，这一步多数时候只是图个安心，但跑一遍总没坏处。

3.2 给用户和组授权：setfacl -m 的基本用法

先建一个测试文件和用户，方便后面演示：

bash复制touch /tmp/acl_test
useradd zhangsan        # 若提示已存在就跳过

给用户 zhangsan 授读写执行权限，并查看结果：

bash复制setfacl -m u:zhangsan:rwx /tmp/acl_test
getfacl /tmp/acl_test

输出大致如下：

code复制# file: tmp/acl_test
# owner: root
# group: root
user::rw-
user:zhangsan:rwx
group::r--
mask::rwx
other::---

注意到没有，getfacl 会自动补上 mask::rwx，因为系统在添加具名用户条目时已经把 mask 重算过了。如果你拒绝系统自动重算，就用 -n 参数，但那样你得自己维护 mask，一般不推荐新手用。

给组授权是一个道理：

bash复制setfacl -m g:devgrp:rwx /tmp/acl_test

撤销某条具名用户权限，用 -x：

bash复制setfacl -x u:zhangsan /tmp/acl_test

清空文件上的所有扩展 ACL，用 -b：

bash复制setfacl -b /tmp/acl_test

对目录递归授权时，加上 -R：

bash复制setfacl -R -m u:zhangsan:r-x /srv/data

这里要提醒一句：-R 只作用于当前已经存在的文件，不会影响以后新建的文件。规划目录继承，必须配合默认 ACL 一起用，下面专门说。

3.3 默认 ACL 的继承规则与目录场景

默认 ACL 的操作，就是在原条目前面加 d: 前缀，表示 default：

bash复制setfacl -m d:u:zhangsan:r-x /srv/data

执行后再 getfacl，会看到输出里多出一组 default: 开头的条目：

code复制user::rwx
user:zhangsan:r-x
group::r-x
mask::r-x
other::---
default:user::rwx
default:user:zhangsan:r-x
default:group::r-x
default:mask::r-x
default:other::---

默认 ACL 的继承有两个细节，非常关键：

第一，它只对"之后新建"的文件和目录生效，已经存在的文件不会自动获得任何新权限。很多人设置了默认 ACL 后发现老文件还是访问不了，排查半天，原因就在这。

第二，继承时内核会用创建文件时给定的 mode 参数做一次掩码计算。对普通文件来说，即使默认 ACL 里带了 x 执行位，新建出来的普通文件通常也不会被继承到 x 位，这是为了防止创建普通文件时意外获得可执行权限；而对新目录，默认 ACL 里的执行位会正常继承，因为目录没有 x 位就没法进入。

如果你想让整个目录树都带上某条权限，正确的做法是分两步：先对已有文件递归设置访问 ACL，再对目录设置默认 ACL。二者缺一不可。

3.4 如何验证某个用户到底能不能操作

配完权限别急着走，实际验证一下是最稳妥的。很多人配完 ACL 只看 getfacl 输出，觉得没问题，结果实际业务一跑就报权限错误。因为 getfacl 显示的是条目的"原始权限"，而真正生效的是经过 mask 限制后的"有效权限"。

验证方法之一，是用 sudo 切换到目标用户，直接做读写测试：

bash复制sudo -u zhangsan cat /srv/data/conf/app.ini
sudo -u zhangsan touch /srv/data/conf/tmp_test

如果不想切来切去，也可以用 test 命令判断：

bash复制sudo -u zhangsan test -r /srv/data/conf/app.ini && echo "可读"
sudo -u zhangsan test -w /srv/data/conf/app.ini && echo "可写"
sudo -u zhangsan test -x /srv/data/conf/ && echo "可进入目录"

再配合 ls -l 看一眼权限位末尾有没有 + 号：

bash复制ls -l /srv/data/conf/app.ini
# -rw-r-----+ 1 root root 1024  ...

那个 + 号表示该文件带有扩展 ACL，没有 + 号就说明 ACL 不存在或者已经被清掉。这个细节可以用来快速判断备份、复制之后 ACL 有没有丢失。

4. 我踩过的几个 ACL 的坑，提前替你趟平

4.1 mask 的"静默降权"现象

我第一次被 mask 坑，是在一台生产服务器上。当时给一个用户单独授了目录的 rwx 权限，getfacl 看的时候也是正常显示 user:zhangsan:rwx，但 zhangsan 实际去写文件，却一直报 permission denied。

我反复确认了条目没问题，最后用 getfacl 仔细一看，才发现输出里那行后面跟着 #effective:r-x，mask 那一行是 mask::r-x。也就是说，权限授予确实没问题，但 mask 这个闸门把 zhangsan 的有效权限限制成了只读。

这个 mask 是怎么变成 r-x 的呢？回溯操作记录才发现，之前某次维护时有人对文件执行了 chmod g-w。在文件已有扩展 ACL 的情况下，chmod 修改的"组权限位"其实改的是 mask，而不是 group:: 条目。这是 POSIX ACL 一个非常容易踩的语义坑——你以为你在调属组权限，实际上把所有人具名条目的上限都降了。

解决办法很简单，把 mask 调回去：

bash复制setfacl -m m::rwx /path/to/file

但更重要的教训是：一旦文件启用了扩展 ACL，就不要再拿 chmod 去改组权限位了，统一用 setfacl 管理。如果你在生产环境维护过这类文件，一定理解我说的是什么意思。

4.2 setfacl 会自动重算 mask，显式收紧反而会失效

上一个坑是"mask 被意外降权"，这一个坑正好相反，是"我明明想收紧 mask，结果又被系统自动放开了"。

场景是这样的：你有一个共享目录，里面有很多具名用户各自的权限，你希望通过把 mask 调整为 r-- 来暂时让所有东西只读。实际操作：

bash复制setfacl -m m::r-- /srv/data

这一步是对的，mask 也确实变成了 r--。问题出在后面：过几天你往 /srv/data 再添加一个新用户的权限，比如：

bash复制setfacl -m u:lisi:rwx /srv/data

如果你没有加 -n 参数，setfacl 会重新计算 mask，把 lisi 的 rwx 也并进去，之前的 r-- 收窄瞬间失效，所有具名条目的有效权限又被放开了。

这是 setfacl 的默认行为，文档里有写，但实际操作中真的会忽略。如果你希望"显式收紧 mask + 添加新用户"不互相影响，要么用 -n 跳过自动重算：

bash复制setfacl -n -m u:lisi:rwx /srv/data

要么在添加完新用户后，重新设一次 mask：

bash复制setfacl -m u:lisi:rwx /srv/data
setfacl -m m::r-- /srv/data

我自己更习惯第二种，因为可读性好，操作记录里一眼能看到收紧动作。总之记住一个原则：mask 不是你设完就可以忘的东西，它和具名用户条目之间是动态联动关系。

4.3 备份恢复：tar 默认不保存 ACL

这是我吃过最大的一次亏。当时要迁移一个带 ACL 的共享目录，我用最顺手的 tar 打了包，到新服务器上解包，结果发现所有具名用户、具名组的 ACL 全部丢失，文件权限退化成了普通 ugo 三组。业务一上线，外包人员的写权限全无，几个人同时报故障。

查原因才发现，GNU tar 默认不会保留 ACL 和扩展属性，你必须显式指定 --acls 参数。所以正确的打包和解包命令应该是：

bash复制# 打包时保留 ACL
tar --acls -czf share_backup.tar.gz /srv/data

# 解包时恢复 ACL
tar --acls -xzf share_backup.tar.gz -C /

其他几个常用工具的 ACL 保留情况，我也给你列个表，省得一个个试：

顺带说一句：如果你们环境里大量使用 rsync 做备份，-a 参数并不包含 -A，这是很多人默认以为"归档模式应该啥都带了"的误区。实际要保留 ACL，必须显式加 -A，要保留扩展属性再加 -X。

4.4 复制、移动与编辑器保存对 ACL 的影响

除了备份工具，日常操作里还有几个容易“偷走” ACL 的小动作。

第一个是 mv 跨文件系统移动。mv 在同一个文件系统内只是改个目录项，inode 没变，ACL 自然还在。但跨文件系统时，mv 行为退化成"复制 + 删除"，这种复制未必会带 ACL。我之前用 mv 把目录从 /home 挪到 /data，挪完发现 ACL 全丢了。现在我的习惯是跨文件系统搬迁一律用 rsync -aAX 或者 cp -a，确认没问题再去删源头。

第二个是编辑器保存文件导致的 ACL 丢失。vim 在 Linux 上默认 writebackup 是开着的，backupcopy 默认 auto，有时保存文件会采用"写临时文件 + rename 替换原文件"的方式。这样一来，原文件被新 inode 替代，新增的 ACL 条目全部丢失。你可能会想：我给配置目录加个默认 ACL 不就行了？但默认 ACL 只作用于新建文件，对替换后的文件同样要重新计算，结果不一定符合预期。最稳妥的做法是：对设置过 ACL 的关键文件，编辑完用 getfacl 复查一次，或者在 vim 里把 backupcopy 设为 yes，让它直接写原文件而不是替换 inode。

第三个是某些同步软件，比如部分版本的 Syncthing、rclone，默认只同步内容，不同步 ACL。如果你用这类工具做文件分发，要专门确认是否支持并开启了 ACL 同步。

4.5 文件系统与网络共享层面的额外提醒

再补充一点，虽然不算 Linux 本机 ACL 的坑，但很多人会在这里钻牛角尖。NFSv4 和 Samba 里提到的"ACL"，跟 Linux 本机的 POSIX ACL 并不是同一套东西。NFSv4 有自己的 ACL 模型，支持更细粒度的权限控制，还包含 deny 规则；Samba 的 Windows ACL 也有一套自己的映射逻辑。如果你在 NFS 挂载的目录上直接 setfacl，或者在 Samba 共享上发现 ACL 不生效，先确认自己操作的到底哪一层，别拿 POSIX ACL 的命令去硬套 NFSv4 的语义。

5. 实战：搭建一个多角色共享目录

5.1 先画授权矩阵

说了这么多，还是做一个完整案例比较直观。假设我们在 /srv/project/share 建一个共享目录，角色和权限需求如下：

看看这个矩阵，传统 chmod 绝对表达不了：devgrp 是属组的话，group:: 可以给 rwx，但审计员和外包用户的差异化权限就只能靠 ACL 来补。流程走一遍，你会发现前面所有知识点都能用上。

5.2 分步配置过程

第一步，创建目录和用户组，设置属主：

bash复制sudo mkdir -p /srv/project/share
sudo groupadd devgrp 2>/dev/null
sudo useradd -G devgrp shenji 2>/dev/null
sudo useradd -G devgrp wailian 2>/dev/null
sudo chown root:devgrp /srv/project/share

第二步，设置传统权限，把 other 权限去掉，同时给属组读写执行：

bash复制sudo chmod 770 /srv/project/share

此时目录权限是 drwxrwx---。审计员和外包用户都不在 devgrp 里，也无法访问，接下来用 ACL 把差异权限补上。

第三步，给审计员授只读，给外包用户授读写执行：

bash复制sudo setfacl -m u:shenji:r-x /srv/project/share
sudo setfacl -m u:wailian:rwx /srv/project/share

到这里，当前目录的访问 ACL 就设置好了。但这还不够，新建的子目录和文件不会自动带上这些差异权限，所以必须设置默认 ACL，让未来的文件自动继承：

bash复制sudo setfacl -m d:u:shenji:r-x /srv/project/share
sudo setfacl -m d:u:wailian:rwx /srv/project/share
sudo setfacl -m d:g:devgrp:rwx /srv/project/share
sudo setfacl -m d:o::--- /srv/project/share

第四步，检查一下最终 ACL：

bash复制getfacl /srv/project/share

输出大致是：

code复制# file: srv/project/share
# owner: root
# group: devgrp
user::rwx
user:shenji:r-x
user:wailian:rwx
group::rwx
mask::rwx
other::---
default:user::rwx
default:user:shenji:r-x
default:user:wailian:rwx
default:group::rwx
default:mask::rwx
default:other::---

注意 mask 自动变成了 rwx，这是 setfacl 根据所有具名条目和 group:: 并集算出来的，符合预期。

第五步，在目录下创建测试文件，验证继承机制：

bash复制sudo -u wailian touch /srv/project/share/test.txt
getfacl /srv/project/share/test.txt

你会发现 test.txt 自动带了 wailian 的 rwx 条目、shenji 的 r-x 条目，这就是默认 ACL 在起作用。如果没有默认 ACL，新建文件的权限只会是 -rw-r-----，审计员和外包用户全都访问不了。

5.3 验证结果：让每个角色各就各位

配置完成后，我建议把关键角色的行为全部验证一遍，避免业务上线后才发现权限不对。

首先验证审计员只能读不能写：

bash复制sudo -u shenji cat /srv/project/share/test.txt && echo "读取成功"
sudo -u shenji touch /srv/project/share/forbidden.txt && echo "写入成功"

正常结果应该是第一条输出读取成功，第二条输出 permission denied。如果审计员能写进去，多半是 mask 或默认 ACL 没设置对，要立刻停下来排查。

接着验证外包用户能正常读写：

bash复制sudo -u wailian touch /srv/project/share/tmp_file.txt && echo "外包写入成功"
sudo -u wailian rm /srv/project/share/tmp_file.txt && echo "外包删除成功"

再验证 devgrp 组的普通成员也能正常操作：

bash复制sudo -u devuser touch /srv/project/share/dev_file.txt && echo "研发写入成功"

最后再验证无权限用户被拒绝：

bash复制sudo -u nobody ls /srv/project/share && echo "访问成功"

这里会提示 permission denied，符合预期。如果你发现 nobody 能进去，检查一下父目录 /srv/project 的权限，看是不是有 other::--- 的遗漏。

5.4 回滚方案与日常管理建议

权限方案上线容易，出问题时能不能快速回滚同样重要。这个共享目录的回滚方案其实很简单：

bash复制# 清除所有扩展 ACL 条目（包括访问 ACL 和默认 ACL）
sudo setfacl -b /srv/project/share
sudo setfacl -k /srv/project/share
# 如果还要清除目录下所有已有文件的 ACL
sudo setfacl -R -b /srv/project/share

setfacl -b 清空访问 ACL，setfacl -k 清空默认 ACL，两个都要执行才干净。清完之后目录回到传统 chmod 的 770 权限，相当于整个目录退回到只有 devgrp 组成员能访问的状态，审计员和外包用户全部失效。也可以先备份一份 ACL 详情，在需要时直接恢复：

bash复制getfacl -R /srv/project/share > acl_backup.txt
# 回滚后或迁移后恢复
setfacl --restore=acl_backup.txt

这个文件我在迁移服务器和误操作回滚时都用过，比手写一堆 setfacl 命令稳得多。

日常管理我给自己定了三条规矩，也分享给你：

1. 共享目录全部启用默认 ACL，任何新增授权都同时设置访问 ACL 和默认 ACL，避免"眼下能访问、以后新文件不行"的隐性故障。
2. 配置 ACL 的路径尽量不做 chmod 组权限变更，需要调整权限时统一用 setfacl，避免误改 mask。
3. 每次修改 ACL 后及时用 getfacl 复核，并同步更新配置文档，至少写清楚每个文件/目录上有哪几条具名条目、mask 是多少。等三个月后再回头看，你会感谢当时的这一笔记录。

最后再分享一点实际心得

ACL 这套东西最大的价值，是把 Linux 文件权限从"三选一"变成了"按人按组配置"，很多以前只能靠加组、放开 other 位才能实现的场景，现在一条 setfacl 就解决了。但它的学习曲线不在命令本身，而在理解 mask 和默认 ACL 这两个联动机制。我见过太多人学会了 setfacl -m 就以为大功告成，结果被 mask 的静默降权、被新文件不继承权限这些问题折腾到怀疑人生。我自己的建议是：先把 5.2 节的案例完整做一遍，再故意制造几个坑（比如用 chmod g-w 改一次权限、加新用户前手动收紧 mask）观察效果，比看十篇文档都管用。权限管理这件事，越接近"精确到人"越值得花时间，因为它省的是后面排故障的无数个小时。