是否存在“所有者”权限的原因？群组权限不够吗？

我想我宁愿了解Linux中文件权限的工作方式。但是，我不太了解为什么将它们分为三个级别而不是两个级别。

我想回答以下问题：

• 这是故意设计还是补丁？也就是说-所有者/组权限是与某些理由一起设计和创建的，还是它们接连出现来满足需求？
• 用户/组/其他方案是否有用但组/其他方案不够用？

第一个答案应引用教科书或官方讨论区。

我考虑过的用例是：

• 私有文件-通过按用户分组可以很容易地获得，通常在许多系统中都可以完成。
• 仅允许所有者（例如系统服务）写入文件，仅允许特定组读取，并拒绝所有其他访问-此示例的问题是，一旦要求对组具有写访问权限，则用户/ group / other失败了。两者的答案都是使用ACL，恕我直言，没有理由所有者权限的存在。

注意：在superuser.com中关闭问题后，我对此问题进行了细化。

EDIT更正了“但组/所有者方案不足”到“ ...组/其他...”。

历史

最初，Unix仅拥有所有者用户和其他用户的权限：没有组。特别是请参阅Unix版本1的文档chmod(1)。因此，向后兼容性（如果没有其他要求）需要拥有用户的权限。

小组后来来了。允许在文件权限中包含多个组的ACL来得很晚。

表现力

与只有两个文件相比，拥有三个文件权限可以提供更精细的权限，而成本却非常低（比ACL低很多）。例如，文件可以具有以下模式rw-r-----：只能由拥有用户写入，而可由组读取。

另一个用例是setuid可执行文件，只能由一组执行。例如，模式为rwsr-x---所拥有的程序root:admin仅允许admin组中的用户以root 用户身份运行该程序。

“有一些方案无法表达的权限”是反对它的可怕论据。适用的标准是，是否有足够的常见可表达案例证明成本合理？在这种情况下，成本是最小的，特别是考虑到用户/组/其他三联画的其他原因。

简单

每个用户只有一个组可以带来很小但不小的管理开销。私有文件的极为常见的情况不依赖于此是很好的。创建私有文件的应用程序（例如，电子邮件传递程序）知道，它所要做的就是为文件提供模式600。它不需要遍历组数据库来查找仅包含用户的组，并且如果没有这样一个小组或一个以上小组怎么办？

从另一个方向来看，假设您看到了一个文件，并且想要审核其权限（即检查它们是否应具有的权限）。当您可以“仅用户可访问，很好，下一步”时，要比需要通过组定义进行跟踪要容易得多。（这种复杂性是大量使用高级功能（例如ACL或功能）的系统的祸根。）

正交性

每个进程都以特定用户和特定组的身份执行文件系统访问（在现代unice上使用更复杂的规则，支持补充组）。用户需要做很多事情，包括测试root（uid 0）和信号传递许可（基于用户）。在区分进程权限中的用户和组与区分文件系统权限中的用户和组之间存在天然的对称性。

这是故意设计还是补丁？也就是说-所有者/组权限是与某些理由一起设计和创建的，还是它们接连出现来满足需求？

文件的用户/组/其他权限是原始Unix设计的一部分。

是否存在用户/组/其他方案有用但组/所有者方案不足的情况？

是的，几乎我能想到的每种情况在安全性和访问控制都很重要的地方。

示例：您可能希望给系统上的一些二进制文件/脚本提供对的仅执行访问权限other，并将读/写访问权限限制为root。

我不确定对于只有所有者/组权限的文件系统权限模型有什么想法。我不知道如果没有other类别，如何拥有一个安全的操作系统。

编辑： 假设您的意思是这里group/other只需要权限，那么我建议设计一种方法来管理加密密钥，或者是只有合适的用户才能访问其邮件后台打印的方法。在某些情况下，私钥可能需要严格的user:user所有权，而在其他情况下，赋予user:group所有权是有意义的。

私有文件-通过按用户分组可以很容易地获得，通常在许多系统中都可以完成。

当然，这很容易做到，但是在存在一个other组的情况下也很容易做到……

仅允许所有者（例如系统服务）写入文件，仅允许特定组读取，并拒绝所有其他访问 -此示例的问题在于，一旦要求对组具有写访问权限，则用户/ group / other失败了。两者的答案都是使用ACL，恕我直言，没有理由所有者权限的存在。

我已经强调了您的陈述部分，这似乎重申了我对otherUnix文件系统权限中某个类别的逻辑必要性的观点。

您似乎正在考虑的文件系统设计（据我所知）将是不安全的或笨拙的。Unix是由一些非常聪明的人设计的，我认为他们的模型可以在安全性和灵活性之间实现最佳平衡。

这是故意设计还是补丁？也就是说-所有者/组权限是与某些理由一起设计和创建的，还是它们接连出现来满足需求？

是的，这是自早期以来就存在于UNIX中的一种经过精心设计的设计。它是在以今天的标准以KB为单位来衡量内存和CPU速度非常慢的系统上实现的。这种查询的大小和速度很重要。ACL将需要更多空间，并且速度会变慢。从功能上讲，该everyone组由其他安全标志表示。

是否存在用户/组/其他方案有用但组/所有者方案不足的情况？

我通常用于文件访问的权限是：（为了简单起见，我使用位值，因为这是我通常设置它们的方式。）

• 600或400：仅用户访问权限（是的，我确实授予用户只读访问权限）。
• 640或660：用户和组访问。
• 644，666或664：用户，组，和其他访问。任何两级权限方案只能处理这三种情况中的两种。第三个将需要ACL。

对于目录和程序，我通常使用：

• 700或500：仅限用户访问
• 750或710：仅组访问
• 755，777，775，或751：用户，组，和其他访问。注释与文件相同。

以上是最常用的，但不是我使用的权限设置的详尽列表。在所有可能使用ACL的情况下，上述权限与组（有时在目录上带有粘性的组位）结合使用就足够了。

如上所述，在目录列表中列出权限非常容易。如果未使用ACL，则我只能使用目录列表来审核访问权限。当我使用基于ACL的系统时，我发现很难验证或审核权限。

用户/组/其他权限系统是在发明ACL之前设计的。它可以追溯到UNIX的早期，因此您不能说应该使用ACL解决该问题。即使ACL的概念似乎很明显，它也会涉及相当大的一天开销，以存储和管理每个文件中可变数量的许可信息，而不是固定数量的许可信息。

对所有内容都使用ACL也意味着您没有清晰定义的权限信息子集，而这些子集可以“一目了然”显示。的输出在一行中ls -l显示了标准（用户/组/其他）权限，用户和组的名称以及与ACL关联的条目的附加符号（例如，+或@符号）。您的系统将要求它标识ACL中的“前两个”组，以提供等效的功能。

另外，在UNIX模型中，文件仍需要具有所有者，因为UNIX ACL不提供允许谁修改ACL。