Re: IIS6 - CGI won't run on 'new website'

From: Jeff Mowatt (jeff_at_albacrest.com)
Date: 10/01/04 

Date: 1 Oct 2004 02:01:50 -0700

"David Wang [Msft]" <someone@online.microsoft.com> wrote in message news:<O9EBkYopEHA.2684@TK2MSFTNGP11.phx.gbl>...
> > When attempting to open the initial static html page which in
> > turn calls the CGI in its form action, a prompt for username
> > and password appears. I enter my adminstrator username
> > and password and the static form is revealed.
> > (This is exactly what happens at the customer too.)
>
> This is a client-side behavior. When you configure a web server to require
> authentication, it is always going to ask for authentication. You see a
> prompt when the browser fails to automatically authenticate an identity to
> the web server. There are many things that control this behavior on the
> client; suffice it to say, there is nothing wrong with the server's
> configuration.
>
> For example, making the following three requests for exactly the same
> resource could have different behavior from the exact same machine and
> browser (assume server.domain.com has Windows name of server and IP of
> 64.63.62.61):
> http://64.63.62.61/static.html
> http://server/static.html
> http://server.domain.com/static.html
>
>
> > I click a button on the form which initiates the form action,
> > calling my CGI.EXE. It shows as a process in the Task
> > Manager window running on behalf of Adminstrator
> > and hangs.
>
> Sounds like your CGI is broken and needs to be debugged. I have seen plenty
> of CGIs that work on both IIS5 and IIS6 without modification, and I've seen
> plenty of CGIs that worked on IIS5 and broke on IIS6. Most of those cases
> end up being bugs/bad-assumptions in the CGI or tightened security
> requirements by IIS6. One of the common reasons is due to IIS6 launching
> all ISAPI/CGI binaries with \\?\ prepended to their paths (for security
> reasons). This notation works across all the Win32 APIs for file IO, but if
> you have a custom path parser and assumes leading "\\" means "UNC share
> access", your code will now be making wrong assumptions. This is a
> fundamental security setting that cannot be configured; any application that
> misinterprets "\\" is broken and needs to be fixed.
>
>
> >In my customer's environment, there is a difference. He is prompted
> > to install and run the exe.
>
> Your customer did not correctly configure execute permissions for the
> vdir/app containing the CGI to have "Scripts and Executables". Hence,
> requests to the resource from your FORM ends up as a download to client
> instead of execute on server.
>
> This behavior is configurable because given this URL: /vdir/myProgram.exe
> -- some users want to download myProgram.exe onto the browser and save/open
> it there
> -- other users want to execute myProgram.exe on the server as a CGI and
> generate a response.
>
> This configuration controls how IIS handles such ambiguous URLs.
>
>
> > I decide to inspect the physical file permissions for my site
> > and discover that they are not set as web shareable,
> > also the IUSR account for my server has no permissions
> > for this folder. I set the folder to web shareable and
> > from the drop-down options I select the name of my
> > new web site, set execute permissions and apply,
> > I then add execute permissions for the IUSR account
> > under the security tab.
>
> I have no idea what you are trying to do here. You manage IIS websites by
> opening the IIS Manager UI from the Start Menu. I have no idea what "web
> shareable" means nor what sort of ACLs you are applying. It doesn't sound
> like you are doing the right things.
>
> Regarding execute permissions -- there are two different ones in play. One
> is at an OS level (right click on the file, properties, security tab). This
> controls whether this file can be directly "executed" by the OS. The other
> one is within IIS, with the Execute Permissions property, and it controls
> how IIS interprets URLs for execution. These are two separate concepts
> because while an ASP page is "executable" by IIS, it is not executable
> binary code as far as the OS is concerned. In other words:
> 1. text.html -- this is considered non-executable by the OS and IIS. IIS
> will simply open the file and serve it to the client
> 2. page.asp -- this is considered non-executable by the OS, and depending on
> Execute Permissions setting, IIS will consider it as either executable
> script or non-executable file. In the non-executable file case, treat it as
> #1. In the executable script case, IIS will invoke ASP.DLL (another
> executable binary) to open the file, parse, and interpret its contents to
> generate responses. Clearly, ASP.DLL must have an Execute ACL in the OS for
> it to be executable.
> 3. program.exe -- this is considered executable by the OS, and depending on
> Execute Permissions setting, IIS will consider it as either executable
> program or non-executable file. In the non-executable file case, treat it as
> #1. In the executable program case, IIS will directly invoke the program to
> generate a response. Clearly, program.exe must have an Execute ACL in the OS
> for it to be executable by IIS through the OS at this point.
>
>
> I hope that you now see how "Execute Permissions" setting in IIS as well as
> the "Execute" ACL in the OS interact.
>
>
> > So it would seem that my app can only work as a virtual directory
> > and setting up as a discrete web site under ISS, I cannot
> > allocate permissions for the site to use the files because
> > IIS Manager seems to prevent me from doing so.
>
> No, a CGI application can work both under a virtual directory as well as its
> own discrete website, and the UI supports configuring both. I also do not
> know what permissions you are configuring -- with default settings, you
> should never need to touch any ACLs because it's all configured to work. If
> you are using custom ACL and security settings, then you are responsible for
> figuring out the combination that works. For example, I frequently just
> copy CGI/ISAPI applications from one machine to another, change IIS
> configuration settings (i.e. just the Execute Permissions setting and adding
> a new Web Service Extension for the CGI/ISAPI application), and everything
> just runs and is secure. No tweaking of ACLs necessary.
>
>
> > My customer should in my view have installed as a virtual folder
> > but has reason to keep the app discrete and fears doing so now
> > will impact on other applications.
>
> The least impactful way to install a CGI is to:
> 1. Put the CGI in its own physical directory
> 2. Create a virtual directory that points to the directory in #1
> 3. Set "Scripts and Executables" permission on the vdir in #2
> 4. Create a new Application Pool
> 5. Set the new Application Pool to the vdir in #2
>
> This CGI will now execute in its own address space, is not involved in any
> other applications, etc. This is how we designed isolation in IIS6.
>
>
> Right now, it sound like you have a problem with your CGI such that even if
> you configure things perfectly things will fail. I suggest you fix the CGI
> first, prior to looking at IIS configuration. If your customer is unwilling
> to follow instructions to install your application correctly, then you
> should probably look for another customer.
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
> "Jeff Mowatt" <jeff@albacrest.com> wrote in message
> news:cca98b1b.0409290354.19bbbc54@posting.google.com...
> I have an inexplicable problem with CGI under IIS6:
>
> I have transferred my CGI based application from IIS5 to IIS6 and
> setting this up as a virtual folder under the Default Web Site,
> allowing scripts and executeables, defining and allowing my CGI.EXE
> under web extensions, I've managed to get it working. So far, so good.
>
> On delivery to my customer, he has chosen to set up as a separate web
> site under IIS. He reports that it fails to function and I replicate
> his installation as a separate web site.
> All the actions which enabled me to run under a virtual folder have
> been applied,both at my customer's site and my own server and the
> results are as follows.
>
> Starting with my server, I'm relating this having opened IE on my
> server whilst logged on as Administrator:
>
> When attempting to open the initial static html page which in turn
> calls the CGI in its form action, a prompt for username and password
> appears. I enter my adminstrator username and password and the static
> form is revealed. (This is exactly what happens at the customer too.)
>
> I click a button on the form which initiates the form action, calling
> my CGI.EXE. It shows as a process in the Task Manager window running
> on behalf of Adminstrator and hangs. I kill this task and my page
> returns an error, unsurprisingly, indicating that a complete set of
> HTTP headers have not been returned.
>
> I repeat the above on my workstation, no username password prompt is
> presented and I go straight to my static html page. Hitting the button
> has the same effect as on the server with the process this time
> running under the name of my workstation logon. I kill the process as
> before and get the same error result back on my browser.
>
> In my customer's environment, there is a difference. He is prompted to
> install and run the exe.
>
> Back to my installation-
>
> I decide to inspect the physical file permissions for my site and
> discover that they are not set as web shareable, also the IUSR account
> for my server has no permissions for this folder.
> I set the folder to web shareable and from the drop-down options I
> select the name of my new web site, set execute permissions and apply,
> I then add execute permissions for the IUSR account under the security
> tab.
>
> When I return to the folder to look at these permissions I find that
> they have reverted to being shareable by the Default Web Site and no
> matter how many times I try this, whether I change it to my web site
> or Administration the result is the same, this change is not applied.
>
> So it would seem that my app can only work as a virtual directory and
> setting up as a discrete web site under ISS, I cannot allocate
> permissions for the site to use the files because IIS Manager seems to
> prevent me from doing so.
>
> I can't find anything else in the online documentation I've read
> relating to this problem or any other user on a discussion group
> reporting this problem.
>
> My customer should in my view have installed as a virtual folder but
> has reason to keep the app discrete and fears doing so now will impact
> on other applications.
>
> Could anyone suggest where I could take this next?
>
> TIA - Jeff Mowatt

Thanks David,

Those tips are certainly going to be helpful though I'm a bit puzzled
about my own server environment where the cgi will run in a virtual
folder, as I wrote.

I'll assume this means the bug you suspect may be folder specific?

BTW the Web Sharing properties I mentioned are found in the OS file
properties you referred to, as are the security permissions for the
IUSR_xxx account, from what you say I take it that these have no
influence on IIS6 behaviour and relate to permissions for IIS to view
files in folders other than the website itself.

Regards,
Jeff