Security question about IIS and Cassini

[Ian]

I am developing a .NET Web Service that acts as a thin calling layer for a
larger object. Thus the larger object runs in the context of the web service
that is calling it, and is therefore subject to the security restrictions of
the Web Server the web service is run through.

All well and good. At the end of the main method call of the larger object,
it instantiates and calls (through a RCW) a method of a legacy COM object
that writes data away to a legacy system whose files are located completely
seperately from the virtual directory of the web service - part of the normal
file system in other words.

The only problem being that IIS will not allow this method to work, in fact
it refuses to call it. However, when the Web Service is called through
Cassini, with its much less stringent security, it allows the legacy DLL to
work no problem and the app works fine.

Running the same DLL through IIS (both 5.0 and 6.0) causes spurious errors
to happen - on 6.0 on our test server I get an InvalidCastExce ption on the
Com interop, when running it on my development workstation using IIS 5.0 I
get an SOAP exception that says it expected a respone of type "text/xml" when
it got "text/xml";encoding UTF-8' (or words to that effect).

I suspect these are caused in some way by security using IIS. But how do I
configure IIS so that my Web Site is able to run a DLL that writes to a
directory completely outside the virtual directory structure of the web
application? I have tried using ordinary Windows Permissions/Security to
allow the Local Service/Network Service accounts to modify and write (r even
execute) in the non-virtual legacy system's home directory, but IIS still
appears to stop it and generate these odd errors.

Any ideas? Under Cassini it all works fine, but Cassini is no good for a
production web server, or even a proper test.

[Claus Konrad [MCSD]]

You are dealing is OS issues here.
When using Casini, the process is owned by the account in which VS is
started. That most often will be yourself (I assume you are administrator,
like most developers sadly are !), hence you can access the dll's.

IIS 5.x is running (and accesing the HD!) in the context of the account
ASPNET.
IIS 6.0 is running (and accessing the HD!) in the context of the app.pool to
which it is configured. By default this would be local service. The local
service does not have permission to access files outside the virtual
directory. Neither does ASPNET.

What to do?
Configure your IIS to run with another local or domain account that indeed
does have read/write access to the folder in question. That should solve your
mistory.
--
rgds.
/Claus Konrad
MCSD.NET (C#)
"Ian" wrote:

I am developing a .NET Web Service that acts as a thin calling layer for a
larger object. Thus the larger object runs in the context of the web service
that is calling it, and is therefore subject to the security restrictions of
the Web Server the web service is run through.

All well and good. At the end of the main method call of the larger object,
it instantiates and calls (through a RCW) a method of a legacy COM object
that writes data away to a legacy system whose files are located completely
seperately from the virtual directory of the web service - part of the normal
file system in other words.

The only problem being that IIS will not allow this method to work, in fact
it refuses to call it. However, when the Web Service is called through
Cassini, with its much less stringent security, it allows the legacy DLL to
work no problem and the app works fine.

Running the same DLL through IIS (both 5.0 and 6.0) causes spurious errors
to happen - on 6.0 on our test server I get an InvalidCastExce ption on the
Com interop, when running it on my development workstation using IIS 5.0 I
get an SOAP exception that says it expected a respone of type "text/xml" when
it got "text/xml";encoding UTF-8' (or words to that effect).

I suspect these are caused in some way by security using IIS. But how do I
configure IIS so that my Web Site is able to run a DLL that writes to a
directory completely outside the virtual directory structure of the web
application? I have tried using ordinary Windows Permissions/Security to
allow the Local Service/Network Service accounts to modify and write (r even
execute) in the non-virtual legacy system's home directory, but IIS still
appears to stop it and generate these odd errors.

Any ideas? Under Cassini it all works fine, but Cassini is no good for a
production web server, or even a proper test.