NSIS takes ownership of IIS system files
- by Lucas
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.
