进一步阅读

进一步阅读

这个文件关于文件 ACL 提到,屏蔽机制是为了解决

...一旦支持 ACL,不知道 ACL 的 POSIX.1 应用程序将不会突然且意外地开始授予附加权限。

这种情况的例子是什么?

如果系统管理员根据这些意图有一个具有扩展 ACL 设置的文件:

  1. 文件所有者应该有rwx权限
  2. 文件组中的用户不应具有访问权限 ( ---)
  3. 其他人不得访问 ( ---)
  4. 上述三者的一个例外是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)前面提到的问题。

进一步阅读

相关内容