Yuv*_*val 21 linux permissions
我想我更了解文件权限在 Linux 中是如何工作的。但是，我真的不明白为什么将它们分成三个级别而不是两个级别。
我想回答以下问题：
第一个答案应该引用教科书或官方讨论板。
我考虑过的用例是：
注意，我在superuser.com 中关闭了这个问题后，改进了这个问题。
编辑将“但组/所有者方案不足以”更正为“...组/其他...”。
Gil*_*il' 25
最初，Unix 只有拥有用户和其他用户的权限：没有组。请参阅 Unix 版本 1 的文档，特别是chmod(1). 所以向后兼容性，如果没有别的，需要拥有用户的权限。
后来组来了。允许在一个文件的权限中涉及多个组的 ACL 出现的时间要晚得多。
对一个文件拥有三个权限允许比只有两个权限更细粒度的权限，而且成本非常低（比 ACL 低很多）。例如，文件可以具有模式rw-r-----：只能由拥有用户写入，由组读取。
另一个用例是只能由一组执行的 setuid 可执行文件。例如，模式为rwsr-x---by的程序root:admin只允许admin组中的用户以root 身份运行该程序。
“有这个方案无法表达的权限”是一个可怕的反对它的论点。适用的标准是，是否有足够多的常见可表达案例来证明成本是合理的？在这种情况下，成本是最低的，特别是考虑到用户/组/其他三联画的其他原因。
每个用户拥有一个组的管理开销很小但并非微不足道。私人文件的极其常见的情况不依赖于此是很好的。创建私有文件的应用程序（例如电子邮件传递程序）知道它需要做的就是为文件提供模式 600。它不需要遍历组数据库来查找仅包含用户的组 - 并且如果没有这样的组或不止一个，该怎么办？
从另一个方向来看，假设您看到一个文件并且想要审核它的权限（即检查它们是否应该是）。与需要跟踪组定义时相比，“仅用户可以访问，很好，下一个”要容易得多。（这种复杂性是大量使用高级功能（如 ACL 或功能）的系统的祸根。）
每个进程都以特定用户和特定组的身份执行文件系统访问（在支持补充组的现代 unice 上有更复杂的规则）。用户用于很多事情，包括测试root（uid 0）和信号传递权限（基于用户）。在进程权限中区分用户和组与在文件系统权限中区分用户和组之间存在自然对称。
Cha*_*oyd 10
这是故意设计还是补丁？也就是说 - 所有者/组权限是根据某种原理设计和创建的，还是它们一个接一个地出现来满足需求？
文件的用户/组/其他权限是原始 Unix 设计的一部分。
是否存在用户/组/其他方案有用但组/所有者方案不够用的情况？
是的，几乎所有我能想象到的安全和访问控制都很重要的场景。
示例：您可能希望在系统上授予某些二进制文件/脚本对 的仅执行访问权限other，并将读/写访问权限限制为root。
对于只有所有者/组权限的文件系统权限模型，我不确定您的想法。我不知道如果不存在other类别，您如何拥有安全的操作系统。
编辑：
假设你在这里的意思group/other是所有需要的权限，那么我建议设计一些方法来管理加密密钥或一种只有合适的用户才能访问他们的邮件池的方法。在某些情况下，私钥可能需要严格的user:user所有权，但在其他情况下，赋予它user:group所有权是有意义的。
私有文件 - 通过为每个用户创建一个组很容易获得，这在许多系统中通常是这样做的。
诚然，这很容易做到，但只要有一个other群体的存在，就同样容易做到……
仅允许所有者（例如系统服务）写入文件，仅允许特定组读取，并拒绝所有其他访问权限- 此示例的问题是一旦要求组具有写入权限，用户/group/other 失败了。两者的答案都是使用 ACL，恕我直言，并不能证明所有者权限的存在是合理的。
我已经强调了你的陈述中似乎重申了我关于otherUnix 文件系统权限类别的逻辑必要性的观点的部分。
您似乎正在考虑的这种文件系统设计（据我所知）要么不安全，要么笨拙。Unix 是由一些非常聪明的人设计的，我认为他们的模型提供了安全性和灵活性的最佳平衡。