An appliction launched by IIS6 (as a result of an HTTP request) is failing to initialize a dll. If I launch it as the administrator when logged in locally by double clicking, all is good.
This app utilizes TLS encryption via a third party DLL called cryptlib. http://www.coastrd.com/smtps/cryptlib This should not be any big deal in itself, as most of my CGI apps use MySQL/zlib/... etc dlls without problem. In this case (probably due to the nature of creating an SSL/TLS session) the app runs fine if launched by double clicking as administrator, but will not run when launched by IIS as the result of an incoming request. IIS uses the account "Internet Guest Account... (... IUSR)" (we assume) to execute the CGI application from a simple web page HTTP POST request.
I have tried giving full control to the IUSR account on the app, the dll and the folder but no joy. Next I broke out ProcMon and looked for an "ACCESS DENIED" result. The only one I could find was as a result of CreateFile Desired Access: Read Attributes, Delete, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, C:\WINDOWS\Debug\UserMode\ChkAcc.log
This is puzzling as my application is not writing to that log file (I assume IIS is so why would it be having a problem?)
Next I compared the ProcMon output for the successful Administrator launch against the IUSR launch and discovered that a "ReadFile" operation was not present in the failed launch. I do not get an ACCESS DENIED error for this, the operation just doesn't happen.
The sequence of sequntial operations for cl32.dll should be: QueryOpen CreateFile CreateFileMapping QueryStandardInformationFile CreateFileMapping CreateFileMapping CloseFile Load Image ReadFile
I assume this is where the DLL is loaded into memory for use.
Instead of the ReadFile operation (in the failed launch) there is: RegOpenKey HKU\S-1-5-21-4122272316-1273673783-4216733774-1003 NAME NOT FOUND
It quacked a little like the "Bypass traverse checking" problem described here http://forums.iis.net/t/1153139.aspx http://technet.microsoft.com/en-us/library/cc739389(WS.10).aspx but that did not solve the problem.
At this point we have exceeded the limit of my knowledge of user accounts and permissions by a large margin. One thing is clear, this a permissions problem. The question is, which permission?
ADDED
Adding ISUR to Administrators: 1. Right-click My Computer on your Desktop and click Manage. 2. When the Computer Management window opens, expand Local Users And Groups 3. Select Groups and double-click Administrators in the right pane. 4. Click the Add button 5. Click Advanced then Find Now and Select IUSR 6. Click OK. 7. Restart IIS
This did NOT fix the issue. I dug up Filemon v7.3 and it is IUSR that is
er.exe:2240 OPEN C:\WINDOWS\system32\USERENV.dll SUCCESS Options: Open Access: 00100021
er.exe:2240 CLOSE C:\WINDOWS\system32\USERENV.dll SUCCESS
er.exe:2240 OPEN C:\WINDOWS\debug\UserMode\ChkAcc.log ACCESS DENIED MY-SERVER\IUSR_MY-SERVER
er.exe:2240 CREATE C:\WINDOWS\debug\UserMode\ChkAcc.log ACCESS DENIED MY-SERVER\IUSR_MY-SERVER
At this point ill take any stabs in the dark at what permission this might be :)
ADDED
I changed the permission on the file ChkAcc.log and the folder UserMode, I also checked the advanced permissions and found a deny on the application and the Dll. I removed them both. I restarted IIS and even re-booted the machine. Still no luck.
I am wondering if the ACCESS DENIED is in fact the problem. I rewrote the app to create and write to a file in that folder and it worked:
OPEN C:\WINDOWS\debug\UserMode\ChkAcc.txt SUCCESS Options: OpenIf Access: 00120196
SET INFORMATION C:\WINDOWS\debug\UserMode\ChkAcc.txt SUCCESS Length: 0
SET INFORMATION C:\WINDOWS\debug\UserMode\ChkAcc.txt SUCCESS Length: 0
WRITE C:\WINDOWS\debug\UserMode\ChkAcc.txt SUCCESS Offset: 0 Length: 41
WRITE C:\WINDOWS\debug\UserMode\ChkAcc.txt SUCCESS Offset: 41 Length: 2
SET INFORMATION C:\WINDOWS\debug\UserMode\ChkAcc.txt SUCCESS Length: 43
SET INFORMATION C:\WINDOWS\debug\UserMode\ChkAcc.txt SUCCESS Length: 43
CLOSE C:\WINDOWS\debug\UserMode\ChkAcc.txt SUCCESS
This leads me to suspect that the folder permission is not the issue at all, but the DLL is failing to initialize for some reason.
Is there some way to give IUSR the identical permissions as ADMIN? then perhaps I can remove them one by one. Perhaps I could even create a second user with ADMIN permissions and have IIS use that instead of IUSR for incoming CGI requests?
Clearly adding IUSR to the ADMIN group is not the same as running the app as ADMIN.
ADDED
Actually the problem turned out to be due to the dll performing various sanity-check tests on startup, including the ability to read files. To do this it tries to read the user's home directory (or in Windows terms the user's profile directory)
In testing on Windows 2003 Server box, I find
IUSR
CSIDL_APPDATA = C:\WINDOWS\system32\config\systemprofile\Application Data
Administrator
CSIDL_APPDATA = C:\Documents and Settings\Administrator.MY-SERVER\Application Data
I suspect that the cgi process is being denied access to any system32 folders. This is behavior I would expect until IUSR is added to the administrators, then I would expect this to work.... yet it doesn't. The solution was to re-write the dll, but I am still puzzled by this
Note the two lines you have:
The first line might be the application checking whether it exists, while the second line makes for a "create file if it does not exist" situation. The things I would look for is that the IUSR account is not part of the "USERS" group, but is part of "GUESTS", and generally guests have even less privileges than "USERS". You may want to ensure that the IUSR account have the ability to TRAVERSE the folders above it. Try giving the IUSR account explicit access to traverse the folders, and the permission on the "UserMode" folder to "Create Files" (but "THIS FOLDER ONLY").
Finally, there maybe explicit "deny" permissions for guests that may prevent you from accessing the folders. Those are the things I would check.