根据已接受的答案这里，这只是因为您不会在通向该文件的目录中进行访问检查。例如，调用openinode(inode #, flags).
我的问题很简单：为什么文件本身还没有必要的访问控制列表（没有那些前导目录）？
是否存在这些领先目录（可能具有不同权限）变得重要的情况？
答案1
假设我有一个包含任意数量的子目录、文件、子子目录等的目录结构。我想删除除特定用户和组之外的所有用户的访问权限。这很容易做到：
chown chosen_user:chosen_group some-directory
chmod ug=rwx,o-rwx some-directory
按照您提出的让每个文件在其元数据中包含访问控制的方法，我必须这样做（或者如果无法直接更改用户/组，例如 setuid 二进制文件，则必须执行其他一些 ACL）对于每个文件。为什么有人想要那个？
答案2
除了上述原因外穆鲁的回答，我想指出，这将针对 POSIX/UNIX 权限系统运行并导致安全漏洞：
POSIX 中的文件通过其名称和路径进行存储、检索、修改、属性和权限检查。这是文件的基本模型：为操作系统提供一个字符串，描述您想要获取的数据片段，这意味着您需要遍历才能获取它的目录层次结构，它会检查您是否可以，并为您提供，如果正常，则以文件描述符的形式访问该数据块。
发生访问权限检查时有一个明确定义的时间点，即您要求操作系统“打开”文件的时间，如上所述。
引入任何其他标识符——甚至不一定是索引节点号，任何东西——如果不经过相同的权限验证过程，那么在多个层面上都是一个安全错误！
规避基于路径的访问控制：您必须可以访问的路径是对您打开文件的权限的限制。使用绑定挂载、硬链接、NFS……打开单个文件可能有不同的方式。这些都可能会导致您可以（或不能）访问该文件的不同权限。 UNIX 说：对文件执行某些操作的权限不仅仅是存储在该文件的文件系统条目中的属性。您的基于 inode 的访问方案禁用了该限制，因此可以规避很多的安全性。
变化：绝对不能保证索引节点保持不变。根本不是合同的一部分。
更糟糕的是：利用，例如：我想读取定期关闭/重命名/重新打开的访问日志。我不能，因为路径说我不能（例如，非特权用户无法读取或执行 /var/log/daemon/，即使文件是 644）。我只是暴力破解所有索引节点，直到打开一个看起来正确的索引节点。塔达。
inode 是一个实现细节。最初的 UNIX 文件系统就有这样的功能，但它还是卡住了。没有理由假设 inode nr 对任何其他/现代文件系统都是“有用”的。事实上，我的猜测是，从纯粹的计数角度来看，在 Linux 内核支持的所有文件系统中，大多数都支持不是根本不存储索引节点号，但这些是由内核“模拟”的。