![进一步阅读](https://linux22.com/image/85011/%E8%BF%9B%E4%B8%80%E6%AD%A5%E9%98%85%E8%AF%BB.png)
这个文件关于文件 ACL 提到,屏蔽机制是为了解决
...一旦支持 ACL,不知道 ACL 的 POSIX.1 应用程序将不会突然且意外地开始授予附加权限。
这种情况的例子是什么?
如果系统管理员根据这些意图有一个具有扩展 ACL 设置的文件:
- 文件所有者应该有
rwx
权限 - 文件组中的用户不应具有访问权限 (
---
) - 其他人不得访问 (
---
) - 上述三者的一个例外是system组对文件
audit
有权限r--
我想文件的相应扩展 ACL 是:
# file: path/to/file
# owner: foo
# group: bar
user::rwx
group::---
group:audit:r--
mask::r--
other::---
在此示例中,如果该mask
机制未到位并且不知道扩展 ACL 的工具尝试将组权限更改为--x
(这是一个稻草人参数),则该group::
条目最终将具有group::--x
.为什么这会“意外地……授予额外的权限”?
# file: path/to/file
# owner: foo
# group: bar
user::rwx
group::--x
group:audit:r--
other::---
根据我的理解,所属组中的用户而不是所属组中的用户audit
将获得执行能力。该组中但非所属组中的用户audit
不会。两组用户都将获得执行能力。我不明白为什么mask
需要它。
如果我误解了什么,请解释一下。我的稻草人可能没有描述引文所谈论的情况。如果是这种情况,请描述这种情况。
答案1
如果掩码及其与位的链接S_IRWXG
不是这种情况,则使用 执行各种标准操作chmod()
并期望它像chmod()
传统上在旧的非 ACL Unix 上一样工作的应用程序将要么留下巨大的安全漏洞,要么看看他们的想法存在安全漏洞:
- 传统的 Unix 应用程序希望能够拒绝对文件、命名管道、设备或目录的所有访问
chmod(…,000)
。在存在 ACL 的情况下,这只会关闭全部用户和组权限(如果旧S_IRWXG
映射到掩码)。如果没有这个,将旧文件权限设置为000
不会影响特定用户/组的任何 ACL 条目,而令人惊讶的是,其他用户/组仍然可以访问该对象。暂时将文件的权限位更改为无访问权限
chmod 000
,然后再次将其更改回来是一种旧的文件锁定机制,在 Unix 获得咨询锁定机制之前使用,该机制- 正如你所看到的 - 人们今天仍在使用。 - 传统的 Unix 脚本期望能够运行
chmod go-rwx
并最终只有对象的所有者能够访问该对象。再次- 正如你所看到的 - 这仍然是公认的智慧即使是现在,距 Unix ACL 发明几十年了。再说一次,除非旧S_IRWXG
映射到掩码,否则该命令不会起作用,因为否则该chmod
命令不会关闭特定用户/组的任何 ACL 条目,从而导致除所有者之外的用户/组保留对某些内容的访问权限是期待易于访问仅有的给业主。 - 在大多数情况下,权限位与 ACL 分开并
and
与 ACL 一起编辑的系统将要求文件权限标志rwxrwxrwx
,这会让许多 Unix 应用程序感到困惑,这些应用程序在看到他们认为是世界可写的内容时会抱怨东西。权限位与 ACL 分开并
or
与 ACL 一起使用的系统将会出现chmod(…,000)
前面提到的问题。
进一步阅读
- 克雷格·鲁宾(1989-08-18)。 为 Unix 系统选择访问控制列表功能的基本原理。 NCSC-TG-020-A。黛安出版。国际标准书号 9780788105548。
- IEEE 计算机协会便携式应用标准委员会(1997 年 10 月)。 信息技术标准草案 — 便携式操作系统接口 (POSIX) — 第 1 部分:系统应用程序接口 (API) — 修正案 #:保护、审计和控制接口 [C 语言] IEEE 1003.1e。草案 17。
- https://unix.stackexchange.com/a/406545/5132