IUSR vs ADMINISTRATOR permissions
IIS6 and IIS7 support windows CGI applications (located in the cgi-bin folder)
These applictions are launched by IIS as a result of an HTTP request or can be launched by the administrator when logged in locally as the admin by double clicking them in the usual way.
I have written many CGI applications and they have all run perfectly (launched either way) until now. My latest 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)" to execute the CGI application.
I have tried giving full control to 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.
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, the operation just doesnt 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?
These applictions are launched by IIS as a result of an HTTP request or can be launched by the administrator when logged in locally as the admin by double clicking them in the usual way.
I have written many CGI applications and they have all run perfectly (launched either way) until now. My latest 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)" to execute the CGI application.
I have tried giving full control to 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.
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, the operation just doesnt 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?
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
timmsie
14 years ago
Think your in the wrong forum. This is a msi packaging forum not IIS
Posted by:
MikeTrader
14 years ago
I have been using Google all day and reading in this forum quite a bit. I realize it is not a perfect match, but any help would be greatly appreciated.
Posted by:
timmsie
14 years ago
well you never know, there are some very clever people on here. Apart from me[;)]
Posted by:
anonymous_9363
14 years ago
I would suuspect that that log file isn't written/accessed because the Admin user would be expected to have the required access privileges. Have you tried assigning write permissions for 'Everyone' to the log file folder?
As to debugging the registry access, clearly the user hive is unavailable. Here's some script to help you with that.
As to debugging the registry access, clearly the user hive is unavailable. Here's some script to help you with that.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.