ACL是Linux中超越传统ugo权限的精细化权限管理机制，允许为多个用户和群组设置独立访问规则。通过getfacl查看、setfacl设置ACL，可实现如多用户协作目录的复杂权限需求；支持默认ACL使新文件自动继承权限，并通过Mask控制最大有效权限，提升安全与管理灵活性。
Linux系统中的ACL（Access Control List）机制，其实就是一种超越传统ugo（所有者、群组、其他人）权限的精细化权限控制方式。它允许你为文件或目录设定更具体的访问规则，比如让多个用户或多个群组拥有不同的读、写、执行权限，而不再受限于一个所有者和一个群组的限制。这在多用户协作或者需要复杂权限管理的环境下，简直是管理者的福音。
解决方案
要使用ACL来设置精细化权限，我们主要会用到两个命令：
getfacl用于查看现有ACL，
setfacl用于设置或修改ACL。
首先，确认你的文件系统支持ACL。大多数现代Linux发行版默认都支持，比如ext4、XFS等。如果你的文件系统不支持，可能需要在挂载时加上
acl选项，或者重新格式化。
1. 查看文件或目录的ACL：
在操作之前，先看看当前文件或目录的ACL状态是很有必要的。
getfacl /path/to/your/file_or_directory
输出会显示所有者、群组、以及可能已经存在的ACL条目。
2. 设置用户或群组的ACL：
这是最常用的功能。你可以为特定的用户（
u:）或群组（
g:）添加权限。 假设我们有一个文件
/data/project_report.txt，希望用户
alice有读写权限，而用户
bob只有读权限。
-
为用户
alice
添加读写权限：setfacl -m u:alice:rw /data/project_report.txt
这里的
-m
表示“修改”或“添加”ACL条目。u:alice:rw
的意思是给用户alice
读（r）和写（w）的权限。 -
为用户
bob
添加只读权限：setfacl -m u:bob:r /data/project_report.txt
-
为特定群组添加权限： 如果你有一个名为
dev_team
的群组，希望他们对某个目录/data/shared_code
有读写执行权限：setfacl -m g:dev_team:rwx /data/shared_code
3. 移除ACL条目：
-
移除特定用户或群组的ACL： 比如，不再让
alice
对/data/project_report.txt
有特殊权限：setfacl -x u:alice /data/project_report.txt
-x
表示“移除”指定的ACL条目。 -
移除所有ACL条目（恢复到传统权限）： 如果你想彻底清除一个文件或目录上的所有ACL设置，可以使用
-b
选项：setfacl -b /data/project_report.txt
这个操作会移除所有扩展ACL条目，包括用户、群组和mask。
4. 复制ACL：
有时候，你可能想把一个文件或目录的ACL设置复制到另一个地方，这在管理大量文件时非常方便。
getfacl /source/path | setfacl --set-file=- /destination/path
这里，
getfacl的输出被管道传递给
setfacl --set-file=-，
--set-file=-表示从标准输入读取ACL规则。
ACL和传统Linux权限有什么区别？什么时候该用ACL？
谈到ACL，就不能不提它和我们熟悉的
chmod、
chown那一套传统权限体系的区别。传统Linux权限，也就是ugo（User, Group, Other），它把权限分成三类：文件所有者、文件所属群组、以及其他所有人。每类只能设置读（r）、写（w）、执行（x）权限，一共就九个位。这套机制简单明了，对大部分场景都够用。
但问题来了，如果我的一个项目目录，需要让
开发组A有读写权限，
测试组B只有读权限，而
项目经理C需要完全控制，并且他不是文件所有者也不是文件所属群组的成员，那传统权限就显得捉襟见肘了。你不能把文件同时属于两个群组，也不能为单个用户额外设置权限而不影响“其他人”。
这时候，ACL就登场了。它就像是在传统权限的基础上打了个补丁，或者说扩展了一层。ACL允许你为任意数量的特定用户和特定群组设置独立的权限条目。这意味着，你可以让
开发组A获得
rwx，
测试组B获得
r-x，同时让
项目经理C获得
rwx，而这一切都不会干扰到文件原本的所有者和群组权限，也不会影响到“其他人”的权限。
什么时候该用ACL呢？ 我的经验是，当你发现传统权限无法满足以下场景时，就是ACL大显身手的时候：
- 多用户/多群组协作的共享目录： 这是最常见的场景。比如一个团队项目，多个小组需要访问同一个目录，但每个小组的权限需求不同。
- 需要为特定个人开放权限，但又不希望他成为文件所有者或改变文件所属群组。 比如一个临时合作者，需要对某些文件有特定权限。
- 权限需求非常精细复杂，传统权限模型无法表达。 比如某些文件需要对所有普通用户隐藏，但对特定管理员可见。
我个人觉得，ACL的引入极大地提升了Linux文件系统权限管理的灵活性。它不是要取代传统权限，而是作为一种补充，解决传统权限的局限性。在使用时，我通常会先尝试用传统权限解决，如果实在不行，才会考虑引入ACL，避免过度复杂化。
ACL中的Mask权限是什么？它如何影响实际权限？
ACL中的Mask（掩码）权限，初次接触时可能会让人有点困惑，但它在ACL体系中扮演着一个非常重要的角色，尤其是在安全性方面。简单来说，Mask定义了所有非拥有者、非“其他”的ACL条目所能拥有的最大有效权限。 它就像一个总闸，限制了通过ACL赋予的额外权限的上限。
我们用
getfacl命令查看ACL时，会看到类似这样的输出：
# file: my_file.txt # owner: user1 # group: group1 user::rw- user:alice:rwx # effective: rwx group::r-- group:dev_team:rw- # effective: rw- mask::rwx other::---
这里的
mask::rwx就是掩码条目。
Mask如何影响实际权限？
对于所有通过
setfacl -m命令添加的命名用户（
user:name）、命名群组（
group:name）以及文件所属群组（
group::）这些ACL条目，它们的有效权限（effective permissions）并不是其自身设置的权限，而是它们自身权限与Mask权限进行逻辑“与”（AND）运算后的结果。
举个例子，如果
user:alice被赋予了
rwx权限，但Mask权限是
r-x（只读和执行），那么
alice的实际有效权限就会变成
r-x。即使她被明确授予了写权限，Mask的存在也会阻止她写入。
# 初始设置 setfacl -m u:alice:rwx my_file.txt getfacl my_file.txt # Output might show: # user:alice:rwx # effective: rwx # mask::rwx # (mask is automatically set to rwx if no other restrictions) # 现在我们手动把mask限制为 r-x setfacl -m m:r-x my_file.txt getfacl my_file.txt # Output will now show: # user:alice:rwx # effective: r-x <-- 注意这里，alice的有效权限被mask限制了 # mask::r-x
为什么需要Mask？
Mask的主要作用在于提供一个全局性的权限限制。当你需要快速收紧对一个文件或目录的额外访问权限时，修改Mask比逐个修改每个ACL条目要高效得多。它提供了一个额外的安全层，确保即使某个ACL条目被错误地赋予了过高的权限，Mask也能将其限制在一个可接受的范围内。
当使用
setfacl -m添加新的ACL条目时，
setfacl命令通常会根据现有ACL条目自动计算并更新Mask，以确保Mask至少包含所有已设置权限的并集。但你也可以像上面例子那样手动设置Mask，这在需要更严格控制时非常有用。理解Mask的工作原理，是掌握ACL精髓的关键一步。
如何为新建文件和目录设置默认ACL？
在多用户协作的环境中，我们经常会遇到这样的需求：在一个共享目录下，所有新创建的文件或子目录，都应该自动继承某些特定的ACL权限。比如，一个项目组的共享目录，希望所有新文件都能被组内成员读写。这时候，普通的ACL设置就不够了，因为它们只对当前文件或目录生效，不会自动应用到后续创建的内容。
为了解决这个问题，ACL引入了默认ACL（Default ACL）的概念。默认ACL是应用在一个目录上的特殊ACL条目，它会指定该目录下新创建的文件和子目录应该继承哪些ACL权限。
设置默认ACL的语法：
在
setfacl命令中，通过在ACL条目前面加上
d:前缀，就可以设置默认ACL。
假设我们有一个共享目录
/data/shared_project，我们希望：
- 用户
dev_user
对所有新文件和子目录有读写执行权限。 - 群组
qa_team
对所有新文件和子目录有只读执行权限。
我们可以这样设置：
# 首先，为目录本身设置默认ACL setfacl -m d:u:dev_user:rwx,d:g:qa_team:r-x /data/shared_project # 还可以为目录本身也设置对应的ACL，确保当前目录也符合预期 setfacl -m u:dev_user:rwx,g:qa_team:r-x /data/shared_project
验证默认ACL的效果：
现在，我们在这个目录下创建一个新文件或子目录，然后查看它的ACL：
cd /data/shared_project touch new_file.txt mkdir new_subdir getfacl new_file.txt # 输出会显示 new_file.txt 继承了默认ACL中为文件设置的权限（通常是d:rwx去掉x） # user:dev_user:rw- # group:qa_team:r-- getfacl new_subdir # 输出会显示 new_subdir 继承了默认ACL中为目录设置的权限 # user:dev_user:rwx # group:qa_team:r-x # default:user:dev_user:rwx (新子目录也会有自己的默认ACL) # default:group:qa_team:r-x
需要注意的几点：
- 只对新创建的内容生效： 默认ACL不会改变目录下已有的文件或子目录的权限。
- 文件和目录的继承差异： 当文件继承默认ACL时，它的执行权限（x）通常会被移除，除非是脚本等需要执行的文件。而子目录则会完整继承默认ACL。
- 默认ACL的默认ACL： 如果一个子目录继承了父目录的默认ACL，那么这个子目录本身也会带上这些默认ACL，这样它的子内容也能继续继承。
-
清理默认ACL： 如果想移除一个目录的默认ACL，可以使用
-k
选项，或者像移除普通ACL一样，用-x d:u:user
或-b
（会移除所有ACL，包括默认的）。setfacl -k /data/shared_project # 移除所有默认ACL条目 # 或者更精确地移除某个默认条目 setfacl -x d:u:dev_user /data/shared_project
设置默认ACL是管理共享目录权限的强大工具，它能大大简化权限维护工作，确保团队协作的顺畅进行。不过，在设置时要格外小心，避免赋予过宽的默认权限，以免造成安全隐患。
