fli*_*ubt 8 svn windows permissions acl installshield
我们的应用程序使用一个组件,该组件在我们的可执行文件的目录中需要一个许可证文件,它恰好是一个.NET WinForms应用程序,尽管我认为这个问题并不重要.当安装在某些XP专业版机器上时(目前为止只有几百个中的三个),该组件会抛出许可证异常.因此,我重新生成了许可证文件并将其发送给组件供应商(EMC Captiva),供应商声称该错误是由于"Users"组对该文件没有读取权限.遇到错误的用户恰好是本地管理员,但除此之外,我仍然对更一般的问题感到好奇.
所以我的问题是,ACL是否存储在一个文件中,以便它们在整个生命周期中都遵循该文件,特别是在我的开发机器(机器1)上生成许可文件,存储在Subversion(机器2)中,从源代码控制中检出由TeamCity(机器3),由InstallShield(机器4)打包到安装程序中,最后部署到客户机器(机器5),由管理员安装它？在我的开发机器(机器1)上生成文件后,通过其支持站点(机器2)将其上载到组件供应商,然后支持人员将其下载到他们的机器上进行检查(机器3)？
我不确定这一点(这就是我在这里问的原因),但我假设每台Windows机器都将ACL存储在NTFS管理的某个中心目录/ list/table中,而不是存储在文件中.当原始文件的ACL从一台机器复制到另一台机器,存储在Subversion中,打包成MSI等时会发生什么？有人能指出一些我可以阅读的好参考资料吗？
Tom*_*lak 15
ACL存储在NTFS分区的一部分中,该分区执行所有后台管道 - MFT(主文件表).
ACL不跟随文件,因为它不是文件的一部分(就像它是元数据的文件名一样).该文件可以跨越分区类型边界(NTFS-> FAT),ACL不能.
现在,如果您在一个NTFS分区中移动文件,您可能会得到ACL实际上遵循该文件的印象.这是因为在移动期间,实际上只改变了MFT中的文件名.其他一切都保持不变.
如果您复制文件或将其移动到另一个分区或计算机(实际上是一个复制+删除操作),复制的文件将默认继承其新容器的权限(确切地说,仅为可继承的容器).
但是,有些工具能够在复制操作之后保留文件的ACL(简单地通过在复制操作之后在目标文件上重新创建它),甚至可以在分区或计算机边界上.xcopy可以做到这一点.
但由于ACL可以包含"域拥有"的SID,因此ACL条目实际上对于不属于同一域的目标计算机实际上没有意义(例如,将NTFS格式化的USB驱动器带回家时).在这种情况下,ACL条目将不起作用.
其他SID"众所周知",如"SYSTEM"SID.这些实际上将跨域边界识别.