我试图理解这种 Unix 行为(我碰巧在 Ubuntu 11.10 上进行测试):
$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--
$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx #effective:--x
group::rw- #effective:---
mask::--x
other::r--
请注意,chmod(1) 命令已更新 ACL 掩码。为什么会发生这种情况?
这SunOS 手册页有以下要说的:
如果使用 chmod(1) 命令更改具有 ACL 条目的文件的文件组所有者权限,则文件组所有者权限和 ACL 掩码都将更改为新权限。请注意,新的 ACL 掩码权限可能会更改具有文件 ACL 条目的其他用户和组的有效权限。
我之所以问这个问题,是因为如果 chmod(1) 没有这种行为,我会觉得很方便。我希望通过理解它为什么会这样做,我可以更好地设计如何设置文件系统权限。
答案1
它会不是chmod()
如果没有这种行为,将会对您很方便。
这会带来极大的不便,因为人们传统上期望在 Unix 上运行的东西会出问题。这种行为对你很有利,你知道吗?
IEEE 1003.1e 从未成为标准,并于 1998 年被撤销,这令人遗憾。实际上,十四年后,它已成为各种操作系统的标准——从Linux通过FreeBSD到索拉里斯——真正去落实。
IEEE 1003.1e 工作草案 #17 读起来很有趣,我推荐它。在附录 B § 23.3 中,工作组提供了详细的八页理由,解释了 POSIX ACL 相对于旧S_IRWXG
组权限标志的工作方式有些复杂。(值得注意的是,TRUSIX 人员在十年前提供了大致相同的分析。)我不会在这里全部复制。请阅读标准草案中的理由以了解详细信息。这是一个非常简短的摘要:
SunOS 手册是错误的。它应该读
如果使用该
chmod(1)
命令更改具有 ACL 条目的文件的文件组所有者权限,任何一个文件组所有者权限或者ACL 掩码已更改为新的权限。这是你可以看到正在发生的事情,尽管当前手册页上说了什么,但在您的问题中。这也是 POSIX 标准草案指定的行为。如果存在
CLASS_OBJ
(Sun 和 TRUSIX 的术语ACL_MASK
)访问控制条目,则 a 的组位chmod()
会将其设置,否则它们会设置GROUP_OBJ
访问控制条目。如果不是这种情况,使用 `chmod()` 执行各种标准操作的应用程序,期望它能够像 `chmod()` 传统上在旧的非 ACL Unix 上工作一样工作,要么会留下巨大的安全漏洞,要么会看到他们认为是巨大的安全漏洞:
传统的 Unix 应用程序希望能够使用 拒绝对文件、命名管道、设备或目录的所有访问
chmod(…,000)
。在存在 ACL 的情况下,这只会关闭全部如果旧S_IRWXG
文件映射到 ,则用户和组权限CLASS_OBJ
将保持不变。如果没有这个,将旧文件权限设置为000
不会影响任何USER
或GROUP
条目,而其他用户却仍然能够访问该对象,这令人惊讶。暂时将文件的权限位更改为禁止访问
chmod 000
,然后再将其改回来,这是一种旧的文件锁定机制,在 Unix 获得建议锁定机制之前使用,它— 如你所见 — 人们至今仍在使用。传统的 Unix 脚本期望能够运行
chmod go-rwx
,并且最终只有对象的所有者才能访问该对象。再次— 如你所见 — 这仍然是公认的观点S_IRWXG
十二年后。同样,除非旧映射到CLASS_OBJ
存在,否则这不起作用,因为否则该chmod
命令不会关闭任何USER
或GROUP
访问控制条目,导致所有者和非所有者组以外的用户保留对某些内容的访问权限是期待可以访问仅有的给主人。and
权限位与 ACL分离且与之关联的系统rwxrwxrwx
在大多数情况下都需要文件权限标志,这会让许多 Unix 应用程序感到困惑,当它们看到它们认为是全世界可写的东西时就会抱怨。or
权限位与 ACL分离且与之关联的系统 可能会出现chmod(…,000)
前面提到的问题。
进一步阅读
- Winfried Trümper(1999-02-28)。 Posix.1e 概要
- IEEE 计算机学会可移植应用程序标准委员会 (1997 年 10 月)。 信息技术草案标准 — 可移植操作系统接口 (POSIX) — 第 1 部分:系统应用程序接口 (API) — 修订号:保护、审计和控制接口 [C 语言] IEEE 1003.1e。草案 17。
- 克雷格·鲁宾(1989-08-18)。 为 Unix 系统选择访问控制列表功能的理由。NCSC-TG-020-A。DIANE 出版。ISBN 9780788105548。
答案2
此行为仅适用于 POSIX ACL 条目。之所以出现这种情况,是因为如果您有一个文件夹,并且该文件夹中有一个文件,则可以将 acl 作为 rwx(例如)文件夹和文件。如果文件的组权限为 rw-(在典型情况下可能如此),则掩码会为 acl 提供 rw- 的有效权限,即使 ACL 明确表示为 rwx。
另一方面,几乎总是 +x 的目录具有有效的 ACL 掩码权限,也允许 +x。
总之,这个掩码基本上用于区分 POSIX ACL 集的文件和文件夹之间的权限,以便文件在通常不应该执行时不会变为可执行文件。