/build/static/layout/Breadcrumb_cap_w.png

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?

0 Comments   [ + ] Show comments

Answers (4)

Posted by: timmsie 14 years ago
Fourth Degree Brown Belt
0
Think your in the wrong forum. This is a msi packaging forum not IIS
Posted by: MikeTrader 14 years ago
Yellow Belt
0
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
Fourth Degree Brown Belt
0
well you never know, there are some very clever people on here. Apart from me[;)]
Posted by: anonymous_9363 14 years ago
Red Belt
0
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.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ