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，避免过度复杂化。

VisDoc

AI文生图表工具

29

查看详情

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

，我们希望：

1. 用户

   dev_user

   对所有新文件和子目录有读写执行权限。

2. 群组

   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是管理共享目录权限的强大工具，它能大大简化权限维护工作，确保团队协作的顺畅进行。不过，在设置时要格外小心，避免赋予过宽的默认权限，以免造成安全隐患。