8

我们的应用程序使用的组件需要目录中的许可证文件和我们的可执行文件，这恰好是一个 .NET WinForms 应用程序，尽管我认为这对这个问题无关紧要。当安装在某些 XP Pro 机器上时（目前只有几百台机器中的三台），该组件会引发许可证异常。所以我重新生成了许可证文件并将其发送给组件供应商 (EMC Captiva)，供应商声称该错误是由于“用户”组对该文件没有读取权限。遇到错误的用户恰好是本地管理员，但除此之外，我仍然对更一般的问题感到好奇。

所以我的问题是，ACL 是否存储在文件中，以便它们在文件的整个生命周期中都跟随文件，特别是当许可证文件是在我的开发机器（机器 1）上生成、存储在 Subversion（机器 2）中、从源代码控制中签出时由 TeamCity（机器 3），由 InstallShield（机器 4）打包成安装程序，最后部署到由管理员安装的客户机器（机器 5）？在我的开发机器（机器 1）上生成文件后，如何通过他们的支持站点（机器 2）将其上传到组件供应商，然后支持人员将其下载到他们的机器以供检查（机器 3）？

我不确定这一点（这就是我在这里问它的原因），但我假设每台 Windows 机器都将 ACL 存储在由 NTFS 管理的某个中央目录/列表/表中，而不是存储在文件中。当原始文件的 ACL 从一台机器复制到另一台机器、存储在 Subversion 中、打包到 MSI 等时，会发生什么情况？有人可以指出我可以阅读的一些好的参考资料吗？

4

1 回答 1

15

ACL 存储在 NTFS 分区的一部分中，该分区执行所有后台管道 - MFT（主文件表）。

ACL 不会跟随文件，因为它不是文件的一部分（就像文件名一样，它是元数据）。文件可以跨越分区类型边界（NTFS->FAT），ACL 不能。

现在，如果您在一个 NTFS 分区内移动一个文件，您可能会觉得 ACL 实际上跟随该文件。这是因为在移动过程中，实际上只更改了 MFT 中的文件名。其他一切都保持不变。

如果您复制文件或将其移动到另一个分区或计算机（实际上是复制+删除操作），则复制的文件将默认继承其新容器的权限（准确地说是可继承的）。

但是，有些工具能够在复制操作后保留文件的 ACL（只需在复制操作后在目标文件上重新创建它），即使在分区或计算机边界上也是如此。xcopy 可以做到这一点，等等。

但由于 ACL 可以包含“域所有”的 SID，因此 ACL 条目可能对不属于同一域的目标计算机实际上没有意义（例如，当带回家一个 NTFS 格式的 USB 驱动器时）。在这种情况下，ACL 条目将不起作用。

其他 SID 是“众所周知的”，例如“SYSTEM”SID。这些实际上将被跨域识别。

于 2009-05-08T12:53:14.727 回答