☰

ACL如何计算文件的有效权限？

tag-icon • tag-icon linux files permissions acl
ACL如何计算文件的有效权限？

我运行以下命令来授予wheel组rwx对创建的新文件和子目录的权限：

[belmin@server1]$ ls -la
total 24
drwxr-sr-x+   2 guards guards  4096 Aug 27 15:30 .
drwxr-xr-x  104 root   root   12288 Aug 27 15:19 ..

[belmin@server1]$ sudo setfacl -m d:g:wheel:rwX .

[belmin@server1]$ getfacl .
# file: .
# owner: guards
# group: guards
# flags: -s-
user::rwx
group::r-x
group:wheel:rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:wheel:rwx
default:mask::rwx
default:other::r-x

但是，当我以 root 身份创建文件时，我并不完全清楚effective权限是如何计算的：

[belmin@server1]$ sudo touch foo

[belmin@server1]$ getfacl foo
# file: foo
# owner: root
# group: guards
user::rw-
group::r-x                      #effective:r--
group:wheel:rwx                 #effective:rw-
group:guards:rwx                #effective:rw-
mask::rw-
other::r--

有人可以详细解释一下这意味着什么吗？

答案1

effective权限是通过将实际（真正的？）权限与mask.由于mask您的文件的 是rw-，因此所有effective权限都已关闭x。

答案2

简短回答：如果您想要执行位打开的掩码，则必须使用setfaclafter显式设置它touch。安全性禁止其隐式设置。

setfacl -n -m m::rwx foo

“-n”抑制掩码的重新计算（可能不需要）。
“m::rwx”将掩码值设置为“rwx”。请注意，“m::x”将禁用所有读取和写入。

我无法说明为什么掩码是“rw-”。我假设touch创建文件的默认目录在整个 OP 示例中保持不变。

  1. “foo”的目录条目应显示所有者“root”（由于 sudo 命令和组“guards”，因为该目录设置了 SUID 位。权限将默认为“-rw-...r--”）目录“-...rx...”的组权限（由于 SUID 位显示为小 s）。

  2. 接下来是 ACL，它应该是目录默认值。鉴于 ACL 具有继承性，我不希望创建任何 ACL，并且 ACL 掩码应为目录默认值“rwx”。

但如果它们被创建，我希望新的 ACLe 将从默认值启动，再次将掩码保留为“rwx”。如果它们不是从默认值启动的，那么这似乎违背了默认 ACL 的想法——“默认”ACL 将仅提供命名用户和命名组 ACL。

现在这就引出了一个问题：掩码 ACLe 应该是什么。我希望它是默认掩码条目中的“rwx”。但它可以用空白掩码创建，然后应用各种法律术语。

  1. 暂定 ACL 为 user::rw-、group::rx、other::r--、group:wheel:rwx、group:guards:rwx 和 mask:::（未设置），我们查阅以下文档setfacl：假设相同的规则适用于文件创建。

有一个条款：

如果 ACL 包含命名用户或命名组条目，并且不存在掩码条目，则会创建包含与组条目相同权限的掩码条目。

如果 ACL 组条目是从文件目录条目创建的，则这会将 ACL 掩码设置为“rx”；如果 ACL 组条目来自默认 ACL，则这会将 ACL 掩码设置为“rx”。 （以太方式，对于这种情况，结果是一样的。）

还有一个条款：

如果默认 ACL 包含命名用户条目或命名组条目，并且不存在掩码条目，则会添加包含与默认默认 ACL 的组条目相同权限的掩码条目。 ...掩码条目的权限被进一步调整，以包括受掩码条目影响的所有权限的并集。

如果应用此规则，则掩码将以“rx”（与上一条相同的逻辑）开头，然后将其调整为“受掩码条目影响的所有权限的并集”。

命令文档中未定义“受掩码条目影响的权限” setfacl。 POSIX ACL 文档说：

掩码是所属组的所有访问权限以及所有用户和组条目的组合。

给出“联合”这个词，它是可加的，我会将“组合”读作逻辑或。换句话说，如果任何组或用户 ACLe 具有“x”权限，则掩码将包含“x”。

  1. 根据所有这些逻辑，OP 示例中的掩码值应该是“rwx”，无论遵循哪个逻辑路径。

上述推理一定是有缺陷的，因为用于执行的 x 没有出现在掩码中。

因此，必须存在一些关于如何计算掩码的规则，这些规则已从公共文档源中“隐藏”（或者我们发现了一个错误）。

我的结论是，“x”总是被无条件删除，而且文档也很松懈。

这一更改可能是出于“安全”的考虑——任何文件都不应是隐式可执行的，但在创建后必须打开可执行位。

相关内容