我想我更了解 Linux 中文件权限的工作原理。但是，我不太明白为什么它们分为三个级别而不是两个级别。
我希望回答以下问题：
- 这是故意设计还是补丁？也就是说，所有者/组权限是与某种理由一起设计和创建的，还是相继出现来满足需求？
- 是否存在用户/组/其他方案有用但组/其他方案不够的情况？
第一个问题的答案应该引用教科书或官方讨论板。
我考虑过的用例是：
- 私有文件 - 通过为每个用户创建一个组，可以很容易地获得，这在许多系统中都是经常做的。
- 仅允许所有者（例如系统服务）写入文件，仅允许特定组读取，并拒绝所有其他访问 - 此示例的问题在于，一旦要求团体为了具有写访问权限，用户/组/其他人会失败。两者的答案都是使用 ACL，恕我直言，这并不能证明所有者权限的存在。
注意：我在问题结束后改进了这个问题超级用户网站。
编辑将“但组/所有者方案不够”更正为“...组/其他...”。
答案1
历史
最初，Unix 仅拥有所属用户的权限，而对于其他用户：没有组。请参阅 Unix 版本 1 的文档，特别是chmod(1)。因此，如果没有别的原因，向后兼容性需要拥有用户的权限。
团体后来来了。允许在一个文件的权限中涉及多个组的 ACL 出现得很晚。
表现力
与只有两个文件相比，拥有三个权限可以以非常低的成本（比 ACL 低很多）获得更细粒度的权限。例如，文件可以具有模式rw-r-----：只能由所属用户写入，可由组读取。
另一个用例是只能由一组执行的 setuid 可执行文件。例如，模式为rwsr-x---by 的程序root:admin仅允许admin组中的用户以 root 身份运行该程序。
“有些权限是这个方案无法表达的”是一个可怕的反对理由。适用的标准是，是否有足够的常见可表达案例来证明成本的合理性？在这种情况下，成本是最小的，特别是考虑到用户/组/其他三联画的其他原因。
简单
每个用户一个组的管理开销虽小但并非微不足道。幸运的是，极其常见的私有文件情况并不依赖于此。创建私有文件的应用程序（例如电子邮件传送程序）知道它需要做的就是为文件指定模式 600。它不需要遍历组数据库来查找仅包含用户的组 - 并且如果没有这样的团体或超过一个怎么办？
从另一个方向来看，假设您看到一个文件并且您想要审核其权限（即检查它们是否是应有的权限）。当您可以“仅可由用户访问，很好，下一步”时，这比您需要跟踪组定义时要容易得多。 （这种复杂性是大量使用 ACL 或功能等高级功能的系统的祸根。）
正交性
每个进程都以特定用户和特定组的身份执行文件系统访问（现代 unice 上有更复杂的规则，支持补充组）。用户用于很多事情，包括测试root（uid 0）和信号传递权限（基于用户）。在进程权限中区分用户和组与在文件系统权限中区分用户和组之间存在天然的对称性。
答案2
这是故意设计还是补丁？也就是说，所有者/组权限是与某种理由一起设计和创建的，还是相继出现来满足需求？
文件的用户/组/其他权限是原始 Unix 设计的一部分。
是否存在用户/组/其他方案有用但组/所有者方案不够的情况？
是的，几乎在我能想象到的所有场景中，安全和访问控制都很重要。
示例：您可能希望为系统上的某些二进制文件/脚本提供对 的仅执行访问权限other，并将读/写访问权限限制为root。
我不确定您对于仅具有所有者/组权限的文件系统权限模型有何想法。我不知道如果没有类别的存在，你如何能够拥有一个安全的操作系统other。
编辑：
假设您的意思是这里group/other只需要权限，那么我建议设计某种方法来管理加密密钥，或者设计一种只有正确的用户才能访问其邮件假脱机的方法。在某些情况下，私钥可能需要严格的user:user所有权，但在其他情况下，赋予其user:group所有权是有意义的。
私有文件 - 通过为每个用户创建一个组，可以很容易地获得，这在许多系统中都是经常做的。
当然，这很容易做到，但如果有一个团体的存在，这也同样容易做到other……
仅允许所有者（例如系统服务）写入文件，仅允许特定组读取，以及拒绝所有其他访问- 此示例的问题在于，一旦要求某个组具有写访问权限，则用户/组/其他人将无法获得该权限。两者的答案都是使用 ACL，在我看来，这并不能证明所有者权限的存在。
我强调了您声明中的一部分，该部分似乎重申了我关于otherUnix 文件系统权限类别的逻辑必要性的观点。
您似乎正在考虑的这种文件系统设计（据我所知）要么不安全，要么难以操作。 Unix 是由一些非常聪明的人设计的，我认为他们的模型在安全性和灵活性之间提供了最佳的平衡。
答案3
这是故意设计还是补丁？也就是说，所有者/组权限是与某种理由一起设计和创建的，还是相继出现来满足需求？
是的，这是一个经过深思熟虑的设计，从早期就存在于 UNIX 中。它是在内存以 KB 为单位衡量的系统上实现的，而按照当今的标准，CPU 的速度极慢。此类查找的大小和速度很重要。 ACL 需要更多空间并且速度更慢。从功能上讲，该everyone组由其他安全标志表示。
是否存在用户/组/其他方案有用但组/所有者方案不够的情况？
我通常用于文件访问的权限是：（为了简单起见，我使用位值，因为这是我通常设置它们的方式。）
600或400：仅限用户访问（是的，我确实授予用户只读访问权限）。640或660：用户和组访问。644、666或664：用户、组和其他访问权限。任何二级权限方案只能处理这三种情况中的两种。第三个需要 ACL。
对于我常用的目录和程序：
700或500：仅限用户访问750或710：仅组访问755、777、775或751：用户、组和其他访问权限。相同的注释适用于文件。
以上是最常用的，但不是我使用的权限设置的详尽列表。在我可能使用 ACL 的所有情况下，上述权限与组（有时与目录上的粘性组位）相结合就足够了。
如上所述，在目录列表中列出权限非常容易。如果不使用 ACL，我可以仅使用目录列表来审核访问权限。当我使用基于 ACL 的系统时，我发现验证或审核权限非常困难。
答案4
用户/组/其他权限系统是在 ACL 发明之前设计的。这可以追溯到 UNIX 的早期，所以你不能说这个问题应该用 ACL 来解决。即使 ACL 的概念看起来很明显，它也会涉及大量的额外开销来存储和管理每个文件的可变数量（而不是固定数量）的权限信息。
对所有内容使用 ACL 还意味着您没有可以“一目了然”显示的明确定义的权限信息子集。的输出ls -l显示标准（用户/组/其他）权限、用户和组的名称以及具有与其关联的 ACL 的条目上的附加符号（例如+或符号），所有这些都在一行中。@您的系统将要求它识别 ACL 中的“前两个”组以提供等效功能。
另外一点，文件仍然需要有UNIX 模型中的所有者，因为 UNIX ACL 没有规定允许谁修改 ACL。