IIS Server Security - Re: IIS 6.0 CGI pipe broken...

Author

Re: IIS 6.0 CGI pipe broken...

Hoch

2004-01-24, 1:54 am

David,

quote:

> I think you misunderstand what AppPoolIdentity means, and I think you
> have ACL'd the files such that the CGI is doomed to fail.
> For CGI, the property CreateProcessAsUser determines whether IIS invokes
> the CGI with the impersonated identity or the process identity. By
> default, IIS uses the impersonated identity.
> So, I believe your CGI is running as IUSR, which even though is
> Administrator,

The appPoolIdentity is located in the properties dialog of the
application pool we created for the CGI. There is a tab called
'Identity' and there you can set a 'Predefined' or 'Configurable'
identity. I have it set to 'Predefined' -> 'Local System'.

quote:

> it does NOT have access to the client
> EXE since you ACL'd it to only Network Service, Local Service, and
> System, so you are getting Access Denied -- I think this is reflected in
> your CGI failing to access its INI file as well.

The client EXE wasn't set only to Network Service, Local Service, and
System. We added this privileges to what it had before: Administrators,
Power Users
and IUSR. IUSR had read and execute permissions. We gave IUSR full control
but doesn't make any difference, we get the CGI error.

quote:

> From an ACL perspective:
> 1. The CGI, since it is URL-accessible, should have permissions for
> IIS_WPG and IUSR, and it should mirror the ACLs on Inetpub\wwwroot
> 2. The EXE, since it's only accessible by the CGI, should only have
> permissions for the identity that CGI uses -- which I presume is the
> impersonated IUSR since you don't need the CGI to run as Local System
> anyway.
> 3. Any other necessary dependencies, as they arrise, should be ACL'd to
> the identity that needs access -- probably just IUSR.

1. The CGI executes fine (but does not connect to the windows .exe).
It is url accessible. As I said before the App pool fot the CGI is
running in Local System. The privileges for the
directory that contains the CGI .exe and its .ini file are:

- Administrators - Full control
- Internet guest account (IUSR) - Full control (just for testing)
- Local Service - Full control
- Network Service - Full control
- System - Full control
- Power Users - Default privileges

2. The directory that contains this windows .exe, .dlls and ini files has
the following privileges:

- Administrators - Full control
- Internet guest account (IUSR) - Full control (just for testing, I know
it is useless here)
- Local Service - Full control
- Network Service - Full control
- System - Full control
- Power Users - Default privileges

IUSR is a member of the administrators group (just for testing). We reset
IIS 6.0 (not just the web server) everytime we do a change.

With this setting we still get the CGI error: unable to access .ini file.
If we stop II 6.0 and start Apache 2.0, the CGI connects to the windows
..exe
and the database application works fine. It is frustrating.

We still think that there is something in the way IIS 6.0 executes the CGI
that breaks the communication with the windows .exe (database client).

quote:

> You should NOT need to give IUSR any access to Windows or System32
> directory. If you've done a blanket ACL change on the system with
> regards
> to IUSR, I cannot help you any further.

We did not do a blanket ACL, just added IUSR with read and execute
permissions
to serveral folders. If we delete this IUSR permissions it doesn't make any
difference, we still get the CGI error.

Thank you in advance!

Hoch.

Hoch

2004-01-24, 1:54 am

David,

quote:

> I think you misunderstand what AppPoolIdentity means, and I think you
> have ACL'd the files such that the CGI is doomed to fail.
> For CGI, the property CreateProcessAsUser determines whether IIS invokes
> the CGI with the impersonated identity or the process identity. By
> default, IIS uses the impersonated identity.
> So, I believe your CGI is running as IUSR, which even though is
> Administrator,

quote:

> it does NOT have access to the client
> EXE since you ACL'd it to only Network Service, Local Service, and
> System, so you are getting Access Denied -- I think this is reflected in
> your CGI failing to access its INI file as well.

quote:

> From an ACL perspective:
> 1. The CGI, since it is URL-accessible, should have permissions for
> IIS_WPG and IUSR, and it should mirror the ACLs on Inetpub\wwwroot
> 2. The EXE, since it's only accessible by the CGI, should only have
> permissions for the identity that CGI uses -- which I presume is the
> impersonated IUSR since you don't need the CGI to run as Local System
> anyway.
> 3. Any other necessary dependencies, as they arrise, should be ACL'd to
> the identity that needs access -- probably just IUSR.

quote:

> You should NOT need to give IUSR any access to Windows or System32
> directory. If you've done a blanket ACL change on the system with
> regards
> to IUSR, I cannot help you any further.

David Wang [Msft]

2004-01-24, 1:54 am

Let me take a step back...

How does your CGI communicate with the client EXE ? Is it launching the EXE
via some form of CreateProcess*() and passing commandline parameters? Or
perhaps some form of CreateFile() using pipes/slots? Or SharedMemory, etc?

The identity of the AppPool has nothing to do with the identity of the CGI
unless you have set the CreateProcessAsUser metabase property to "false".
So, I'm looking at the user you authenticate with (which is controlled by
the vdir's Authentication setting as well as your browser [who is doing
auto-logon on your behalf unless otherwise configured]).

I believe the identity is IUSR, so now my question moves to what privilege
is lacking on the IUSR account in the CGI's process. You're saying that it
works using RUNAS with the IUSR account (I presume you also set the IUSR
account password properly in the metabase after this). That helps me narrow
down the difference to the privileges held on the Token due to how it's
created or inherited by the CGI process.

Of course for an experiment, you can try to set the AppPool to be
LocalSystem and then set CreateProcessAsUser to be 0 -- then your CGI would
run as LocalSystem... which should work if it's a privileges problem.

But, I do want to know what communication type is failing for you (so that I
can try this and get the developer to look at it)...

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Hoch" <Hoch@fightspammers.com> wrote in message
news:oprzkcpxrmxbnazm@localhost...
David,

quote:

> I think you misunderstand what AppPoolIdentity means, and I think you
> have ACL'd the files such that the CGI is doomed to fail.
> For CGI, the property CreateProcessAsUser determines whether IIS invokes
> the CGI with the impersonated identity or the process identity. By
> default, IIS uses the impersonated identity.
> So, I believe your CGI is running as IUSR, which even though is
> Administrator,

quote:

> it does NOT have access to the client
> EXE since you ACL'd it to only Network Service, Local Service, and
> System, so you are getting Access Denied -- I think this is reflected in
> your CGI failing to access its INI file as well.

quote:

> From an ACL perspective:
> 1. The CGI, since it is URL-accessible, should have permissions for
> IIS_WPG and IUSR, and it should mirror the ACLs on Inetpub\wwwroot
> 2. The EXE, since it's only accessible by the CGI, should only have
> permissions for the identity that CGI uses -- which I presume is the
> impersonated IUSR since you don't need the CGI to run as Local System
> anyway.
> 3. Any other necessary dependencies, as they arrise, should be ACL'd to
> the identity that needs access -- probably just IUSR.

quote:

> You should NOT need to give IUSR any access to Windows or System32
> directory. If you've done a blanket ACL change on the system with
> regards
> to IUSR, I cannot help you any further.

Hoch

2004-01-24, 1:55 am

David,

First of all, thank you for your patiente. And sorry for
the delays answering your posts.

quote:

> How does your CGI communicate with the client EXE ? Is it launching the
> EXE via some form of CreateProcess*() and passing commandline
> parameters? Or
> perhaps some form of CreateFile() using pipes/slots? Or SharedMemory,
> etc?

It comunicates with the windows app via named pipes. We did not
developed the CGI. It is a commercial soft that has been working
great with IIS4 since 1997 and it works fine with Apache 2.0.48
(the last version) so I assume
that it should work with IIS6. It is a very simple CGI that
sends GET/POST and other params that it gets from IIS to the Windows app
(database client).
This database client does the hard work of creating a dynamic HTML page.
Then sends it to the CGI using named pipes and the CGI sends it to IIS4.

quote:

> The identity of the AppPool has nothing to do with the identity of the
> CGI unless you have set the CreateProcessAsUser metabase property to
> "false". So, I'm looking at the user you authenticate with
> (which is controlled by
> the vdir's Authentication setting as well as your browser [who is doing
> auto-logon on your behalf unless otherwise configured]).

No we haven't set CreateProcessAsUser to 'false'.

quote:

> I believe the identity is IUSR, so now my question moves to what
> privilege is lacking on the IUSR account in the CGI's process.
> You're saying that it works using RUNAS with the IUSR account
> (I presume you also set the IUSR account password properly
> in the metabase after this). That helps me narrow down the difference
> to the privileges held on the Token
> due to how it's created or inherited by the CGI process.

Yes the identity is IUSR.
Yes if I execute the CGI (.exe) from the command line using runas IUSR
It connects to the windows app (client database). So there is something
in IIS that breaks the communication. Maybe some setting related to
security of the named pipes used between the CGI and the client
database?
The CGI gets executed fine by IIS so the IUSR privileges are fine and
the password is ok. But it does not connect to the client database.

quote:

> Of course for an experiment, you can try to set the AppPool to be
> LocalSystem and then set CreateProcessAsUser to be 0 -- then your CGI
> would run as LocalSystem... which should work if it's a privileges
> problem.

I will try and let you know what happends.

quote:

> But, I do want to know what communication type is failing for you (so
> that I can try this and get the developer to look at it)...

Thank you in advance!

Hoch.

David Wang [Msft]

2004-01-24, 1:55 am

Ok, thanks for the details.

I'm going to have the developers look at this. The key differences I see
are:
1. The LogonUser call made by IIS is possibly different than RunAs (with
different restrictions)
2. The CreateProcess* call made by IIS to create the CGI is possibly
different than RunAs.
3. [Possible] The pipe name is in some restricted namespace

One last thing:
It seems like this CGI is "paired" with this Windows Client App because it
has intimate knowledge of the name of the Named Pipe that the Windows Client
App is using. Can you use Process Explorer (from sysinternals.com) to find
out what is the name of this Named Pipe? You should be able to just run the
Windows Client App, browse to its EXE name from Process Explorer, and the
name of the Named Pipe should be listed there

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Hoch" <Hoch@fightspammers.com> wrote in message
news:oprzryp2srxbnazm@localhost...
David,

First of all, thank you for your patiente. And sorry for
the delays answering your posts.

quote:

> How does your CGI communicate with the client EXE ? Is it launching the
> EXE via some form of CreateProcess*() and passing commandline
> parameters? Or
> perhaps some form of CreateFile() using pipes/slots? Or SharedMemory,
> etc?

quote:

> The identity of the AppPool has nothing to do with the identity of the
> CGI unless you have set the CreateProcessAsUser metabase property to
> "false". So, I'm looking at the user you authenticate with
> (which is controlled by
> the vdir's Authentication setting as well as your browser [who is doing
> auto-logon on your behalf unless otherwise configured]).

No we haven't set CreateProcessAsUser to 'false'.

quote:

> I believe the identity is IUSR, so now my question moves to what
> privilege is lacking on the IUSR account in the CGI's process.
> You're saying that it works using RUNAS with the IUSR account
> (I presume you also set the IUSR account password properly
> in the metabase after this). That helps me narrow down the difference
> to the privileges held on the Token
> due to how it's created or inherited by the CGI process.

quote:

> Of course for an experiment, you can try to set the AppPool to be
> LocalSystem and then set CreateProcessAsUser to be 0 -- then your CGI
> would run as LocalSystem... which should work if it's a privileges
> problem.

I will try and let you know what happends.

quote:

> But, I do want to know what communication type is failing for you (so
> that I can try this and get the developer to look at it)...

Thank you in advance!

Hoch.

Hoch

2004-01-24, 1:55 am

David,

quote:

> I'm going to have the developers look at this. The key differences I see
> are:
> 1. The LogonUser call made by IIS is possibly different than RunAs (with
> different restrictions)
> 2. The CreateProcess* call made by IIS to create the CGI is possibly
> different than RunAs.
> 3. [Possible] The pipe name is in some restricted namespace

We tried your suggestion of setting CreateProcess to 0 but we still
get the error of the CGI being unable to access its ini file.

quote:

> One last thing:
> It seems like this CGI is "paired" with this Windows Client App because
> it has intimate knowledge of the name of the Named Pipe that the Windows
> Client App is using. Can you use Process Explorer (from
> sysinternals.com) to find out what is the name of this Named Pipe? You
> should be able to just run the Windows Client App, browse to its EXE
> name from Process Explorer, and the
> name of the Named Pipe should be listed there

The name of the named pipe of the Windows App is Device\NamedPipe\Cgi32

I also can send you a log created with Filemon (also from sysinternals)
were you can see how the CGI connects ok with Apache and how it breaks
with IIS 6.0.

If you want to contact me directly use this address: 'comercial' in this
domain: 'shopsland.com'

Thank you again!

Hoch.

David Wang [Msft]

2004-01-24, 1:55 am

The developer and tester have been looking at this. They've noted to me
that as IUSR, we can create and connect to Named Pipes with our test CGI --
so we are thinking it's either a problem based on the name (and scope) of
the Named Pipe, or there is an ACL on the Named pipe (and the user doesn't
have the necessary privilege to impersonate, so it fails to connect).

As for access to the INI file -- I have no idea what that has anything to do
with a named pipe -- so I'm not certain we're even looking at the right
problem any more. FileMon should be able to show what file is failing to be
accessed and why.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Hoch" <Hoch@fightspammers.com> wrote in message
news:oprzyidwuixbnazm@localhost...
David,

quote:

> I'm going to have the developers look at this. The key differences I see
> are:
> 1. The LogonUser call made by IIS is possibly different than RunAs (with
> different restrictions)
> 2. The CreateProcess* call made by IIS to create the CGI is possibly
> different than RunAs.
> 3. [Possible] The pipe name is in some restricted namespace

We tried your suggestion of setting CreateProcess to 0 but we still
get the error of the CGI being unable to access its ini file.

quote:

> One last thing:
> It seems like this CGI is "paired" with this Windows Client App because
> it has intimate knowledge of the name of the Named Pipe that the Windows
> Client App is using. Can you use Process Explorer (from
> sysinternals.com) to find out what is the name of this Named Pipe? You
> should be able to just run the Windows Client App, browse to its EXE
> name from Process Explorer, and the
> name of the Named Pipe should be listed there

Hoch

2004-01-24, 1:55 am

David,

quote:

> I'm going to have the developers look at this. The key differences I see
> are:
> 1. The LogonUser call made by IIS is possibly different than RunAs (with
> different restrictions)
> 2. The CreateProcess* call made by IIS to create the CGI is possibly
> different than RunAs.
> 3. [Possible] The pipe name is in some restricted namespace

We tried your suggestion of setting CreateProcess to 0 but we still
get the error of the CGI being unable to access its ini file.

quote:

> One last thing:
> It seems like this CGI is "paired" with this Windows Client App because
> it has intimate knowledge of the name of the Named Pipe that the Windows
> Client App is using. Can you use Process Explorer (from
> sysinternals.com) to find out what is the name of this Named Pipe? You
> should be able to just run the Windows Client App, browse to its EXE
> name from Process Explorer, and the
> name of the Named Pipe should be listed there

Hoch

2004-01-24, 1:56 am

David,

I describe here what I see in Filemon:

A. when I run the CGI as IUSR in the command line (with success),
B. when the CGI gets executed by Apache 2.0.48 (with success)
C. when the CGI gets executed by IIS 6.0 (fails).

A. This is what I see in Filemon when I execute the CGI from the
command line as IUSR:

1. First the CGI reads 23 times its .ini file,
2. Then it reads and writes some info in Device\NamedPipe\Cgi32
(the pipe of the database client app) probably the IIS params.
3. Afther that the database client this info from the Cgi32 pipe and
processes the request and writes back the HTML page to the same pipe.
4. The CGI reads the HTML code from the Cgi32 pipe and displays it
in command.com. Of course it is an error page, but an HTML page generated
by
the database client (windows app) so the connection is successfull.

C. This is what I see in Apache:

1. Apache executes the CGI with success,
2. Then the CGI reads 23 times its .ini file,
3. Then it reads and writes some info in Device\NamedPipe\Cgi32
(the pipe of the database client app), probably the IIS params.
4. Afther that the database client reads info from the Cgi32 pipe and
processes the request and writes back the HTML page to the same pipe.
5. Then Apache reads from the Cgi32 pipe and everything goes as
expected.

D. And this what is see in IIS 6.0:

1. w3wp.exe executes the cgi with success,
2. The CGI reads its ini file ONLY ONCE with success,
3. Then the CGI writes something to the IISCgiStdOut pipe with success,
probably the error in HTML 'Could not open script configuration' (that
means it could
not access some parameters from the .ini file), that we see in
Internet Explorer.
4. Then w3wp.exe reads from IISCgiStdOut BUT something goes wrong
and filemon displays a 'pipe broken' message,
5. Then w3wp.exe and the CGI close IIScCgiStdOut and IIScCgiStdIn pipes.

The strange thing about IIS 6.0 is that the cgi reads the .ini file only
once instead of 23 so the CGI never accesses the Cgi32 pipe (it has to
read 22 times more from the ini file to get to that point).

How can I check if there is an ACL on the Cgi Named pipe? Although I not
so sure this is the problem.

Hope that this will help.

Thank you again! :-)

Hoch.

On Wed, 10 Dec 2003 01:57:47 -0800, David Wang [Msft]
<someone@online.microsoft.com> wrote:

quote:

> The developer and tester have been looking at this. They've noted to me
> that as IUSR, we can create and connect to Named Pipes with our test CGI
> --
> so we are thinking it's either a problem based on the name (and scope) of
> the Named Pipe, or there is an ACL on the Named pipe (and the user
> doesn't
> have the necessary privilege to impersonate, so it fails to connect).
>
> As for access to the INI file -- I have no idea what that has anything
> to do
> with a named pipe -- so I'm not certain we're even looking at the right
> problem any more. FileMon should be able to show what file is failing
> to be
> accessed and why.
>

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

David Wang [Msft]

2004-01-24, 1:56 am

The "Pipe broken" (Win32 error 109) is likely irrelevant to this issue.
That error does not involve the app's CGI pipe. It comes about because your
CGI failed to generate a complete and valid response and is completely
harmless to IIS... so you might as well consider it "by-design".

So, the REAL problem here is why the CGI cannot access its INI file. Can
you give the ACL on the INI file? Is this INI file located on the local
hard drive or a network-mounted hard drive?

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Hoch" <Hoch@fightspammers.com> wrote in message
news:oprz0e5pgcxbnazm@localhost...
David,

I describe here what I see in Filemon:

A. when I run the CGI as IUSR in the command line (with success),
B. when the CGI gets executed by Apache 2.0.48 (with success)
C. when the CGI gets executed by IIS 6.0 (fails).

A. This is what I see in Filemon when I execute the CGI from the
command line as IUSR:

1. First the CGI reads 23 times its .ini file,
2. Then it reads and writes some info in Device\NamedPipe\Cgi32
(the pipe of the database client app) probably the IIS params.
3. Afther that the database client this info from the Cgi32 pipe and
processes the request and writes back the HTML page to the same pipe.
4. The CGI reads the HTML code from the Cgi32 pipe and displays it
in command.com. Of course it is an error page, but an HTML page generated
by
the database client (windows app) so the connection is successfull.

C. This is what I see in Apache:

1. Apache executes the CGI with success,
2. Then the CGI reads 23 times its .ini file,
3. Then it reads and writes some info in Device\NamedPipe\Cgi32
(the pipe of the database client app), probably the IIS params.
4. Afther that the database client reads info from the Cgi32 pipe and
processes the request and writes back the HTML page to the same pipe.
5. Then Apache reads from the Cgi32 pipe and everything goes as
expected.

D. And this what is see in IIS 6.0:

1. w3wp.exe executes the cgi with success,
2. The CGI reads its ini file ONLY ONCE with success,
3. Then the CGI writes something to the IISCgiStdOut pipe with success,
probably the error in HTML 'Could not open script configuration' (that
means it could
not access some parameters from the .ini file), that we see in
Internet Explorer.
4. Then w3wp.exe reads from IISCgiStdOut BUT something goes wrong
and filemon displays a 'pipe broken' message,
5. Then w3wp.exe and the CGI close IIScCgiStdOut and IIScCgiStdIn pipes.

The strange thing about IIS 6.0 is that the cgi reads the .ini file only
once instead of 23 so the CGI never accesses the Cgi32 pipe (it has to
read 22 times more from the ini file to get to that point).

How can I check if there is an ACL on the Cgi Named pipe? Although I not
so sure this is the problem.

Hope that this will help.

Thank you again! :-)

Hoch.

On Wed, 10 Dec 2003 01:57:47 -0800, David Wang [Msft]
<someone@online.microsoft.com> wrote:

quote:

> The developer and tester have been looking at this. They've noted to me
> that as IUSR, we can create and connect to Named Pipes with our test CGI
> --
> so we are thinking it's either a problem based on the name (and scope) of
> the Named Pipe, or there is an ACL on the Named pipe (and the user
> doesn't
> have the necessary privilege to impersonate, so it fails to connect).
>
> As for access to the INI file -- I have no idea what that has anything
> to do
> with a named pipe -- so I'm not certain we're even looking at the right
> problem any more. FileMon should be able to show what file is failing
> to be
> accessed and why.
>

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Hoch

2004-01-24, 1:56 am

David,

Thank you for your patience,

quote:

> So, the REAL problem here is why the CGI cannot access its INI file. Can
> you give the ACL on the INI file? Is this INI file located on the local
> hard drive or a network-mounted hard drive?

The file is located on the local disc, on a virtual dir in IIS 6.0.
The virtual dir has set anonymous acces throught IUSR.
I double checked the password and it is ok.

The folder contains 3 files: the cgi .exe a .lib file and the .ini file.
That's all. It has this ACLs (same as the cgi .exe):

IUSR - Full control (just to test, I know this should be read & execute)
Local service - Full control
Network servie - Full control
System - Full control
Administrators - Full control
Power users - Modify

All of them inherited mostly from the directory that contains the cgi.

Thank you in avance.

Hoch.

On Sat, 13 Dec 2003 14:56:51 -0800, David Wang [Msft]
<someone@online.microsoft.com> wrote:

quote:

> The "Pipe broken" (Win32 error 109) is likely irrelevant to this issue.
> That error does not involve the app's CGI pipe. It comes about because
> your
> CGI failed to generate a complete and valid response and is completely
> harmless to IIS... so you might as well consider it "by-design".
>
> So, the REAL problem here is why the CGI cannot access its INI file. Can
> you give the ACL on the INI file? Is this INI file located on the local
> hard drive or a network-mounted hard drive?
>

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Hoch

2004-01-24, 1:57 am

David,

Thank you for your patience,

quote:

> So, the REAL problem here is why the CGI cannot access its INI file. Can
> you give the ACL on the INI file? Is this INI file located on the local
> hard drive or a network-mounted hard drive?

quote:

> The "Pipe broken" (Win32 error 109) is likely irrelevant to this issue.
> That error does not involve the app's CGI pipe. It comes about because
> your
> CGI failed to generate a complete and valid response and is completely
> harmless to IIS... so you might as well consider it "by-design".
>
> So, the REAL problem here is why the CGI cannot access its INI file. Can
> you give the ACL on the INI file? Is this INI file located on the local
> hard drive or a network-mounted hard drive?
>

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Hoch

2004-01-24, 1:57 am

David,

We did two additional tests:

On Windows 2000 Pro + IIS 5.0:
1. The CGI+client database work fine on Windows 2000 with
IIS 5.0. Just installed IIS 5.0. Created a virtual dir for
the CGI with execute script in the properties dialog of
the virtual server and it works great.

On a Windows server 2003 + IIS 6.0 (fresh install):
1. We installed the CGI and database client on a Server 2003
with a fresh install of IIS 6.0. We created the virtual dir
for the CGI and set it to execute scripts. Same steps as
we took when installing on Windows 2000 + IIS 5.0 and it
does not work. The CGI is unable to access its .ini file.

Bottom line: Our CGI + database client works fine with
Apache 2.0.48, IIS 4.0 and IIS 5.0 but it does not work
in IIS 6.0 even if we enable the IIS 5.0 compatibility mode.

So, there must be something in IIS 6.0 that prevents the
correct execution of this CGI and I do not think is an
ACL problem.

If you want I can send you the CGI stub, it is very small,
70k, so yo can test what is going wrong. Our address is
'comercial' at 'shopsland.com'

Thank you in advance! :-)

Hoch.

David Wang [Msft]

2004-01-24, 1:57 am

To be clear -- unable to access an INI file usually points to a permissions
issue, not a problem with how IIS "executes" a CGI.

IIS executes a CGI the same way IIS4/5 does -- call CreateProcess* on it.

I will hand this info to the CGI tester to try out.

On a whim -- can you add IIS_WPG List+Read ACLs to the CGI and INI file and
see?

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Hoch" <Hoch@fightspammers.com> wrote in message
news:oprz9k3riuxbnazm@localhost...
David,

We did two additional tests:

On Windows 2000 Pro + IIS 5.0:
1. The CGI+client database work fine on Windows 2000 with
IIS 5.0. Just installed IIS 5.0. Created a virtual dir for
the CGI with execute script in the properties dialog of
the virtual server and it works great.

On a Windows server 2003 + IIS 6.0 (fresh install):
1. We installed the CGI and database client on a Server 2003
with a fresh install of IIS 6.0. We created the virtual dir
for the CGI and set it to execute scripts. Same steps as
we took when installing on Windows 2000 + IIS 5.0 and it
does not work. The CGI is unable to access its .ini file.

Bottom line: Our CGI + database client works fine with
Apache 2.0.48, IIS 4.0 and IIS 5.0 but it does not work
in IIS 6.0 even if we enable the IIS 5.0 compatibility mode.

So, there must be something in IIS 6.0 that prevents the
correct execution of this CGI and I do not think is an
ACL problem.

If you want I can send you the CGI stub, it is very small,
70k, so yo can test what is going wrong. Our address is
'comercial' at 'shopsland.com'

Thank you in advance! :-)

Hoch.

David Wang [Msft]

2004-01-24, 1:58 am

The CGI tester asked about any assumptions made by the CGI for "Current
Working Directory" in the process of loading up its INI file (i.e. does it
ever load the INI file successfully or just failed all the time)?

Many people are on vacation now, so progress probably won't happen until
after New Years Day.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Hoch" <Hoch@fightspammers.com> wrote in message
news:oprz9k3rg6xbnazm@localhost...
David,

Thank you for your patience,

quote:

> So, the REAL problem here is why the CGI cannot access its INI file. Can
> you give the ACL on the INI file? Is this INI file located on the local
> hard drive or a network-mounted hard drive?

quote:

> The "Pipe broken" (Win32 error 109) is likely irrelevant to this issue.
> That error does not involve the app's CGI pipe. It comes about because
> your
> CGI failed to generate a complete and valid response and is completely
> harmless to IIS... so you might as well consider it "by-design".
>
> So, the REAL problem here is why the CGI cannot access its INI file. Can
> you give the ACL on the INI file? Is this INI file located on the local
> hard drive or a network-mounted hard drive?
>

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

David Wang [Msft]

2004-01-24, 1:58 am

Ok, I played with the CGI a bit, and I think I've come upon the cause of the
CGI not running, but I do not know why (yet). The CGI is perfectly able to
read the INI file; it doesn't seem to like the name of the CGI or INI file

Can you verify: On the commandline, launch
NTSD -g \\?\<full_path_to_CGI>.EXE

You will see error returned. If you remove \\?\ , you will probably see
success.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:utx85ITyDHA.2116@TK2MSFTNGP11.phx.gbl...
The CGI tester asked about any assumptions made by the CGI for "Current
Working Directory" in the process of loading up its INI file (i.e. does it
ever load the INI file successfully or just failed all the time)?

Many people are on vacation now, so progress probably won't happen until
after New Years Day.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Hoch" <Hoch@fightspammers.com> wrote in message
news:oprz9k3rg6xbnazm@localhost...
David,

Thank you for your patience,

quote:

> So, the REAL problem here is why the CGI cannot access its INI file. Can
> you give the ACL on the INI file? Is this INI file located on the local
> hard drive or a network-mounted hard drive?

quote:

> The "Pipe broken" (Win32 error 109) is likely irrelevant to this issue.
> That error does not involve the app's CGI pipe. It comes about because
> your
> CGI failed to generate a complete and valid response and is completely
> harmless to IIS... so you might as well consider it "by-design".
>
> So, the REAL problem here is why the CGI cannot access its INI file. Can
> you give the ACL on the INI file? Is this INI file located on the local
> hard drive or a network-mounted hard drive?
>

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Hoch

2004-01-24, 1:58 am

David,

quote:

> The CGI tester asked about any assumptions made by the CGI for "Current
> Working Directory" in the process of loading up its INI file (i.e. does
> it ever load the INI file successfully or just failed all the time)?

With IIS 6.0 it fails all the time. With IIS 4, 5, Apache, tinyweb and
KF server it works always (with IIS 5 it works as IIS process and isolated.
'Medium (pooled)' does not work).

I suppose that the nls_cgi.exe assumes that the ini file is in the
same directory as the .exe. But (maybe) for some reason with IIS 6 the
current directory changes. I tried to place the ini file in different
locations outside the cgi directory but it does not work.

quote:

> Many people are on vacation now, so progress probably won't happen until
> after New Years Day.

It's ok. Thank you for holding on this! :-)

Hoch.

Hoch

2004-01-24, 1:58 am

On Tue, 23 Dec 2003 11:27:05 -0800, David Wang [Msft]
<someone@online.microsoft.com> wrote:

quote:

> Ok, I played with the CGI a bit, and I think I've come upon the cause of
> the CGI not running, but I do not know why (yet). The CGI is perfectly
> able to read the INI file; it doesn't seem to like the name of the CGI
> or INI file
>
> Can you verify: On the commandline, launch
> NTSD -g \\?\<full_path_to_CGI>.EXE
>
> You will see error returned. If you remove \\?\ , you will probably see
> success.

Verified. You are right. If I remove \\?\ I see success and connect to
the database. I'm not familiar with the debugger so I do not know what
all the errors mean. What I see is that when I use
\\?\<full_path_to_CGI>.EXE
there are several errors of the type "The call to LoadLibrary(xxx) failed
Win32 error 2" Do you know what they mean?

Thanks again. Happy Christmas and happy new year! :-)

Hoch.

David Wang [Msft]

2004-01-24, 1:58 am

I've been looking at the CGI, and I do not think GetCurrentDirectory is an
issue. It is pointed at the right place. Besides, the CGI uses the
location of the EXE file to find its INI file. In the error case, the one
file access made by the CGI is to the INI file to read the error string...
so the problem is not that it cannot find the INI file. It definitely can
read the INI file (which it does using GetPrivateProfileString -- a 16bit
API).

It looks to me that the CGI does NOT like its module name prepended with
\\?\ for some reason (I'm suspecting it has some bad logic that thinks it's
a UNC server/share name, so it chokes on a server named "?").

\\?\ disables filessytem cannonicalization and is one security change that
IIS6 uses uniformly for all resource access. Win32 API deal with \\?\
correctly, so problems with this tend to be specific to the app.

I will have to talk with the CGI dev after the holidays. I'm also looking
at why the CGI is breaking on \\?\ (It's not easy without symbols since it's
all assembly).

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Hoch" <Hoch@fightspammers.com> wrote in message
news:opr0ory8hkxbnazm@localhost...
On Tue, 23 Dec 2003 11:27:05 -0800, David Wang [Msft]
<someone@online.microsoft.com> wrote:

quote:

> Ok, I played with the CGI a bit, and I think I've come upon the cause of
> the CGI not running, but I do not know why (yet). The CGI is perfectly
> able to read the INI file; it doesn't seem to like the name of the CGI
> or INI file
>
> Can you verify: On the commandline, launch
> NTSD -g \\?\<full_path_to_CGI>.EXE
>
> You will see error returned. If you remove \\?\ , you will probably see
> success.

Hoch

2004-01-24, 1:58 am

David,

Wow! You got it! Thanks!

Do you think there is any work around?

Thanks again! :-)

Hoch.

On Thu, 25 Dec 2003 13:57:01 -0800, David Wang [Msft]
<someone@online.microsoft.com> wrote:

quote:

> I've been looking at the CGI, and I do not think GetCurrentDirectory is
> an
> issue. It is pointed at the right place. Besides, the CGI uses the
> location of the EXE file to find its INI file. In the error case, the
> one
> file access made by the CGI is to the INI file to read the error
> string...
> so the problem is not that it cannot find the INI file. It definitely
> can
> read the INI file (which it does using GetPrivateProfileString -- a 16bit
> API).
>
> It looks to me that the CGI does NOT like its module name prepended with
> \\?\ for some reason (I'm suspecting it has some bad logic that thinks
> it's
> a UNC server/share name, so it chokes on a server named "?").
>
> \\?\ disables filessytem cannonicalization and is one security change
> that
> IIS6 uses uniformly for all resource access. Win32 API deal with \\?\
> correctly, so problems with this tend to be specific to the app.
>
> I will have to talk with the CGI dev after the holidays. I'm also
> looking
> at why the CGI is breaking on \\?\ (It's not easy without symbols since
> it's
> all assembly).

Hoch

2004-01-24, 2:00 am

David,

Wow! You got it! Thanks!

Do you think there is any work around?

Thanks again! :-)

Hoch.

On Thu, 25 Dec 2003 13:57:01 -0800, David Wang [Msft]
<someone@online.microsoft.com> wrote:

I've been looking at the CGI, and I do not think GetCurrentDirectory is an
issue. It is pointed at the right place. Besides, the CGI uses the
location of the EXE file to find its INI file. In the error case, the one
file access made by the CGI is to the INI file to read the error string...
so the problem is not that it cannot find the INI file. It definitely can
read the INI file (which it does using GetPrivateProfileString -- a 16bit
API).

It looks to me that the CGI does NOT like its module name prepended with
\\?\ for some reason (I'm suspecting it has some bad logic that thinks it's
a UNC server/share name, so it chokes on a server named "?").

\\?\ disables filessytem cannonicalization and is one security change that
IIS6 uses uniformly for all resource access. Win32 API deal with \\?\
correctly, so problems with this tend to be specific to the app.

I will have to talk with the CGI dev after the holidays. I'm also looking
at why the CGI is breaking on \\?\ (It's not easy without symbols since
it's
all assembly).

David Wang [Msft]

2004-01-24, 2:01 am

I asked the CGI developer concerning \\?\ , and I do not think there is a
work-around. IIS6 is going to prepend \\?\ since it is an integral part of
security (on the flip-side, this does say something about Apache on
Windows's non-use of the feature and possible canonicalization attacks
against it).

I think the bug is in the CGI itself since \\?\ works in all the system
calls the CGI makes. It definitely checked its pathname prior to execution,
and it didn't like "\\" for some reason (I'll need source code comments to
determine that, which I do not have access to). It then bailed out with an
error string, ironically retrieved from its own INI file which also has \\?\
prepended, but it didn't seem to care about that.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Hoch" <Hoch@fightspammers.com> wrote in message
news:opr1kjobbuxbnazm@localhost...
David,

Wow! You got it! Thanks!

Do you think there is any work around?

Thanks again! :-)

Hoch.

On Thu, 25 Dec 2003 13:57:01 -0800, David Wang [Msft]
<someone@online.microsoft.com> wrote:

I've been looking at the CGI, and I do not think GetCurrentDirectory is an
issue. It is pointed at the right place. Besides, the CGI uses the
location of the EXE file to find its INI file. In the error case, the one
file access made by the CGI is to the INI file to read the error string...
so the problem is not that it cannot find the INI file. It definitely can
read the INI file (which it does using GetPrivateProfileString -- a 16bit
API).

It looks to me that the CGI does NOT like its module name prepended with
\\?\ for some reason (I'm suspecting it has some bad logic that thinks it's
a UNC server/share name, so it chokes on a server named "?").

\\?\ disables filessytem cannonicalization and is one security change that
IIS6 uses uniformly for all resource access. Win32 API deal with \\?\
correctly, so problems with this tend to be specific to the app.

I will have to talk with the CGI dev after the holidays. I'm also looking
at why the CGI is breaking on \\?\ (It's not easy without symbols since
it's
all assembly).