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，避免过度复杂化。
火山写作
字节跳动推出的中英文AI写作、语法纠错、智能润色工具，是一款集成创作、润色、纠错、改写、翻译等能力的中英文 AI 写作助手。
166 查看详情
ACL中的Mask权限是什么？它如何影响实际权限？
ACL中的Mask（掩码）权限，初次接触时可能会让人有点困惑，但它在ACL体系中扮演着一个非常重要的角色，尤其是在安全性方面。简单来说，Mask定义了所有非拥有者、非“其他”的ACL条目所能拥有的最大有效权限。 它就像一个总闸，限制了通过ACL赋予的额外权限的上限。
我们用
getfacl
命令查看ACL时，会看到类似这样的输出：
# file: my_file.txt# owner: user1# group: group1user::rw-user:alice:rwx # effective: rwxgroup::r--group:dev_team:rw- # effective: rw-mask::rwxother::---
这里的
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.txtgetfacl 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-xsetfacl -m m:r-x my_file.txtgetfacl 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
对所有新文件和子目录有只读执行权限。
我们可以这样设置：
# 首先，为目录本身设置默认ACLsetfacl -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_projecttouch new_file.txtmkdir new_subdirgetfacl 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是管理共享目录权限的强大工具，它能大大简化权限维护工作，确保团队协作的顺畅进行。不过，在设置时要格外小心，避免赋予过宽的默认权限，以免造成安全隐患。
以上就是Linux如何使用ACL设置精细化权限的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/803087.html
微信扫一扫 
支付宝扫一扫 
