|
Home > Archive > IIS Server Security > August 2004 > Trusted Assemblies are untrusted after being overwritten
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Trusted Assemblies are untrusted after being overwritten
|
|
| Jeff Greenland 2004-08-04, 2:50 am |
| I've got something that seems to me like there's a simple
solutions I haven't found.
First, I have a Windows 2003 Server and IIS6 running
a .NET application. I have configured my application
files to be located on a network share, rather than the
local machine. Security and everything is all set up.
In order for the application to work properly, I need a
few assemblies to be trusted, which is simple enough. I
just trust the .DLL files using the .NET Configuration
Tool.
The problem arises when I make a code change in the
development environment, then copy the new .DLL to the
share location to overwrite the old .DLL that's already
trusted. As soon as I do that, the worker processes
reset (as they should), but when they start back up, the
updated .DLL is no longer trusted. I have to use
the .NET Configuration Tool to re-trust it each time I
update the code.
Surely there's a simpler solution. Especially since this
is a high availability application where many IIS servers
are accessing the assembly on the share. I can't have
my "high availability" services all simultaneously stop
functioning because I updated some code.
Any suggestions? Thanks in advance,
Jeff
| |
| Toby Herring 2004-08-05, 8:37 am |
| I think you and Microsoft have a fundamental difference in your way of
thinking.
As far as MS is concerned, if you're regularly making changes to the code,
then it is a development and/or test system, not a "high availability"
production system.
As far as your actual problem goes, this happens because the trusted DLL is
registered according to its strong name. The strong name changes every time
you recompile the code, unless there is absolutely no difference at all
between the two assemblies (not even revision number).
..Net assemblies were DESIGNED to be this way, specifically so that the O/S
can tell two different dll files apart, even if they have the same name and
version info. This is a security feature.
--
Toby Herring
MCDBA, MCSD, MCP+SB
"Jeff Greenland" <jeffg@goldsystems.com> wrote in message
news:bb7101c479e6$c5b2e0d0$a601280a@phx.gbl...
> I've got something that seems to me like there's a simple
> solutions I haven't found.
>
> First, I have a Windows 2003 Server and IIS6 running
> a .NET application. I have configured my application
> files to be located on a network share, rather than the
> local machine. Security and everything is all set up.
>
> In order for the application to work properly, I need a
> few assemblies to be trusted, which is simple enough. I
> just trust the .DLL files using the .NET Configuration
> Tool.
>
> The problem arises when I make a code change in the
> development environment, then copy the new .DLL to the
> share location to overwrite the old .DLL that's already
> trusted. As soon as I do that, the worker processes
> reset (as they should), but when they start back up, the
> updated .DLL is no longer trusted. I have to use
> the .NET Configuration Tool to re-trust it each time I
> update the code.
>
> Surely there's a simpler solution. Especially since this
> is a high availability application where many IIS servers
> are accessing the assembly on the share. I can't have
> my "high availability" services all simultaneously stop
> functioning because I updated some code.
>
> Any suggestions? Thanks in advance,
>
> Jeff
| |
|
| So what's the correct way to update code in a production
environment? Surely nobody builds something that never
needs updating or changing.
These aren't "regular" changes per se, but this is a
large, ongoing application where features are added now
and then. The client and developers are constantly
thinking of and adding new features to make it a better
application. It's not something that's done hourly,
daily, or even weekly for the most part.
I understand the design and features of the security
module and that it is necessary for all to work well
together.
Maybe my fundamental understanding is flawed for a high
availability front-end web service. I have two or more
IIS servers that need to run this application, and all
need to operate from the same directory structure. That
directory structure, of course, contains the .DLL
assemblies that need to be trusted since they are not on
the local hard disk of any one server.
Ideally it would be nice to say "give full trust to any
assembly on any server as long as it's my domain" or
something similar.
Thanks for your input thus far. I hope you can provide
further insight that clears this up.
Jeff
>-----Original Message-----
>I think you and Microsoft have a fundamental difference
in your way of
>thinking.
>
>As far as MS is concerned, if you're regularly making
changes to the code,
>then it is a development and/or test system, not a "high
availability"
>production system.
>
>As far as your actual problem goes, this happens because
the trusted DLL is
>registered according to its strong name. The strong
name changes every time
>you recompile the code, unless there is absolutely no
difference at all
>between the two assemblies (not even revision number).
>
>..Net assemblies were DESIGNED to be this way,
specifically so that the O/S
>can tell two different dll files apart, even if they
have the same name and
>version info. This is a security feature.
>
>--
>Toby Herring
>MCDBA, MCSD, MCP+SB
>
>
>"Jeff Greenland" <jeffg@goldsystems.com> wrote in message
>news:bb7101c479e6$c5b2e0d0$a601280a@phx.gbl...
simple[vbcol=seagreen]
I[vbcol=seagreen]
the[vbcol=seagreen]
this[vbcol=seagreen]
servers[vbcol=seagreen]
>
>
>.
>
| |
|
| And maybe as another question, is there a way to raise
the trust level of an assembly using command-line tools?
>-----Original Message-----
>So what's the correct way to update code in a production
>environment? Surely nobody builds something that never
>needs updating or changing.
>
>These aren't "regular" changes per se, but this is a
>large, ongoing application where features are added now
>and then. The client and developers are constantly
>thinking of and adding new features to make it a better
>application. It's not something that's done hourly,
>daily, or even weekly for the most part.
>
>I understand the design and features of the security
>module and that it is necessary for all to work well
>together.
>
>Maybe my fundamental understanding is flawed for a high
>availability front-end web service. I have two or more
>IIS servers that need to run this application, and all
>need to operate from the same directory structure. That
>directory structure, of course, contains the .DLL
>assemblies that need to be trusted since they are not on
>the local hard disk of any one server.
>
>Ideally it would be nice to say "give full trust to any
>assembly on any server as long as it's my domain" or
>something similar.
>
>Thanks for your input thus far. I hope you can provide
>further insight that clears this up.
>
>Jeff
>
>
>
>
>in your way of
>changes to the code,
a "high[vbcol=seagreen]
>availability"
because[vbcol=seagreen]
>the trusted DLL is
>name changes every time
>difference at all
>specifically so that the O/S
>have the same name and
message[vbcol=seagreen]
>simple
the[vbcol=seagreen]
a[vbcol=seagreen]
enough.[vbcol=seagreen]
>I
already[vbcol=seagreen]
>the
>this
>servers
stop[vbcol=seagreen]
>.
>
|
|
|
|
|