![Windows 文件系统安全继承如何工作?](https://linux22.com/image/519477/Windows%20%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E5%AE%89%E5%85%A8%E7%BB%A7%E6%89%BF%E5%A6%82%E4%BD%95%E5%B7%A5%E4%BD%9C%EF%BC%9F.png)
我正在深入研究功能强大但相当复杂的 Windows 文件/文件夹安全世界。我非常了解这一切是如何运作的,并且可以对 ACL/ACE 机制的工作原理做出一些有根据的猜测。我不确定的是继承标志/机制是如何实现的。
如果(比如说)文件夹对象设置了继承标志,则对父级进行更改:
- 在对父级权限进行更改时,是否复制到所有受影响的子对象?
- 当需要时(例如检查权限),Windows 是否会沿着树往回走以确定继承的权限?
我怀疑是 #1,因为如果您更改大型文件系统根目录的安全权限,则需要很长时间才能应用更改。我假设 Windows 正在遍历所有文件和文件夹,检查继承标志并更改每个对象的 ACL/ACE。
我进一步假设这样做是为了提高性能——不断地走一个非常深的文件夹结构来获取根对象,因为权限是从那里继承的,这将对性能产生相当大的影响。
干杯,罗布。
答案1
根据您提到的“文件夹结构”,我猜您正在谈论 NTFS 权限继承。
正如您所猜测的,NTFS 权限继承实际上是一种巧妙的假象,在修改“可继承” ACL 或创建文件时,明确将“继承” ACL 分配给对象。此行为是被认为是有缺陷的一些人(包括我)对此表示赞同。当您在此类层次结构的根目录下更改权限时,shell 调用来更改权限的 API 将导致此“遍历”到深层文件夹层次结构。(当您已将不可继承的权限添加到深层层次结构的根目录,但必须等待权限“遍历”完成后 shell 才能将控制权返回给您时,这种行为尤其令人恼火。)
我不知道这个设计决定背后的理由是什么,只能说这种行为保留了与旧版 NTFS 的一定程度的兼容性,而且以这种方式实现机制可能更容易(更少的极端情况)。我的理解是,例如,Netware 文件系统实际上实现了继承权限的实时计算,而不是像 NTFS 那样显式标记“非继承”ACL。我想说,Netware 文件系统证明了这种实时计算的权限模型可以有效地实现,并且性能合理。