NSIS 取得 IIS 系统文件的所有权
我最近遇到了 NSIS 的一个问题，我认为该问题与与 UAC 的交互有关，但我无法解释它，并且我不知道将来如何防止它。
我有一个使用 NsisIIS 插件创建和删除 IIS 虚拟目录的安装程序。安装程序在我的 Windows 7 工作站上运行正常。当安装程序在Windows 2008 R2服务器上运行时，它安装正常，但卸载程序删除了所有虚拟目录并使IIS处于无法使用状态；以至于我不得不删除默认网站并重新添加它。
我最终发现，C:\Windows\System32\inetsrv\config 下的所有 IIS 配置文件上都有一个锁图标。
一些 调查似乎表明这意味着用户帐户已获得该文件的所有权，但是列出的所有文件 SYSTEM 作为文件所有者。我确实检查了另一台未运行安装程序的服务器，它没有将锁定图标应用于 IIS 文件。
我还看到 NSIS 安装程序创建的其他文件上出现了相同的锁定图标。例如，我有一个使用 NSIS ReplaceInFile 处理的 Web.Config.tpl 文件，该文件在安装程序完成后也会显示锁定图标。 
在我明确授予另一个用户帐户访问该文件的权限后，锁定图标消失。
我在 2008 R2 服务器上的本地管理员帐户下运行安装程序，所以我不得到UAC提示。以下是 install.nsi 文件中的相关代码
RequestExecutionLevel admin
Section "Application" APP_SECTION
SectionIn RO
Call InstallApp
SectionEnd
Section "un.Uninstaller Section"
Delete "$PROGRAMFILES\${PROGRAMFILESDIR}\Uninstall.exe"
Call un.InstallApp
SectionEnd
Function InstallApp
File /oname=Web.Config Web.Config.tpl
!insertmacro ReplaceInFile Web.Config %CONNECTION_STRING% $CONNECTION_STRING
FunctionEnd
Function un.InstallApp
ReadRegStr $0 HKLM "Software\${REGKEY}" "VirtualDir"
NsisIIS::DeleteVDir "$0"
Pop $0
FunctionEnd
我对这次事件有三个疑问：
- 这是怎么发生的？
- 如何修复我的安装程序以防止再次发生这种情况？
- 如何修复 IIS 配置文件的权限。
I recently encountered an issue with NSIS that I believe is related to an interaction with UAC, but I am at a loss to explain it and I do not know how to prevent it in the future.
I have an installer that creates and removes IIS virtual directories using the NsisIIS plugin. The installer appeared worked correctly on my Windows 7 workstation. When the installer was run on a Windows 2008 R2 server it installed properly, but the uninstaller removed all of the virtual directories and put IIS is an unusable state; to the point that I had to remove the Default Web Site and re-add it.
What I eventually found was that all of the IIS configuration files under C:\Windows\System32\inetsrv\config had a lock icon on them.
Some investigation seem to indicate that this means a user account has taken ownership of the file, however all the files listed SYSTEM as the file owner. I did check a different server that I have not run the installer on, and it does not have the lock icon applied to the IIS files.
I have also seen the same lock icon appear on other files that the NSIS installer creates. For instance, I have a Web.Config.tpl file that is processed using the NSIS ReplaceInFile which also appears with the lock icon after the installer finished.
After I explicitly grant another user account access to the file, the lock icon goes away.
I run the installer under the local Administrator account on the 2008 R2 server, so I do not get the UAC prompt. Here is the relevant code from the install.nsi file
RequestExecutionLevel admin
Section "Application" APP_SECTION
SectionIn RO
Call InstallApp
SectionEnd
Section "un.Uninstaller Section"
Delete "$PROGRAMFILES\${PROGRAMFILESDIR}\Uninstall.exe"
Call un.InstallApp
SectionEnd
Function InstallApp
File /oname=Web.Config Web.Config.tpl
!insertmacro ReplaceInFile Web.Config %CONNECTION_STRING% $CONNECTION_STRING
FunctionEnd
Function un.InstallApp
ReadRegStr $0 HKLM "Software\${REGKEY}" "VirtualDir"
NsisIIS::DeleteVDir "$0"
Pop $0
FunctionEnd
I have three questions stemming from this incident:
- How did this happen?
- How can I fix my installer to prevent it from happening again?
- How can I repair the permissions on the IIS config files.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
ReplaceInFile 宏执行删除和重命名操作，这可能会弄乱文件安全信息。您可以尝试通过在要修改的文件副本上使用宏来解决此问题，然后使用 FileOpen 并逐行复制新内容。
IIS 插件使用 IIS COM 接口，不太确定那里会出现什么问题。确保不将空字符串传递给 NsisIIS::DeleteVDir 可能是个好主意。
The ReplaceInFile macro does a delete and rename dance, it is possible that this messes up the file security information. You could try to work around this by using the macro on a copy of the file you want to modify and then use FileOpen and copy in the new content line by line.
The IIS plugin uses the IIS COM interface, not really sure what could go wrong there. It is probably a good idea to make sure that you don't pass a empty string to NsisIIS::DeleteVDir.