Override existing class name with custom assembly?

[Thomas Christmann]

Hi!

I have a rather special question here. I'd like to write a wrapper
for a .NET assembly, and register that on my server so that the people on
my server call my assembly instead of the standard .NET assembly. Reason
is that I want to include some additional security checks in my assembly,
to prevent everybody from the calling the .NET assembly unchecked. So,
writing the wrapper is no problem, but I'm not sure how/if it is possible
to register my assembly on the server to be called *instead* of the
original assembly, using the original name. So, e.g. if the customer
creates an instance of System.Data.OleDb.OleDbCommand, I want an instance
from *my* System.Data.OleDb.OleDbCommand to be created (that in turn will
eventually create an instance of the real System.Data.OleDb.OleDbCommand,
granted the caller will pass my security checks). I don't want the customer
to have to call something like System.Data.MyCustomOleDb.OleDbCommand,
since my class won't be available at their client computer when they create
their apps, and it will be just easier otherwise.
I remember that achieving the above was no probelm with COM, but is it
possible in .NET as well?

TIA,

Thomas

[Jay B. Harlow [MVP - Outlook]]

Thomas,
My understanding is the security built into .NET prevents this from
happening for largely the opposite reason then you are wanting it to happen.

In that with .NET security I cannot introduce an assembly that reduces the
security of the standard assemblies.

I cannot replace the System.Data.OleDb.OleDbCommand with an object that will
bypass the System.Data.OleDb.OleDbPermission permissions.

For a good starting point on articles on .NET security see:
http://msdn.microsoft.com/library/de...rksecurity.asp

Hope this helps
Jay

"Thomas Christmann" <th***************@online.de> wrote in message
news:5t***************************@40tude.net...

Hi!

I have a rather special question here. I'd like to write a wrapper
for a .NET assembly, and register that on my server so that the people on
my server call my assembly instead of the standard .NET assembly. Reason
is that I want to include some additional security checks in my assembly,
to prevent everybody from the calling the .NET assembly unchecked. So,
writing the wrapper is no problem, but I'm not sure how/if it is possible
to register my assembly on the server to be called *instead* of the
original assembly, using the original name. So, e.g. if the customer
creates an instance of System.Data.OleDb.OleDbCommand, I want an instance
from *my* System.Data.OleDb.OleDbCommand to be created (that in turn will
eventually create an instance of the real System.Data.OleDb.OleDbCommand,
granted the caller will pass my security checks). I don't want the customer to have to call something like System.Data.MyCustomOleDb.OleDbCommand,
since my class won't be available at their client computer when they create their apps, and it will be just easier otherwise.
I remember that achieving the above was no probelm with COM, but is it
possible in .NET as well?

TIA,

Thomas

[Jay B. Harlow [MVP - Outlook]]

Thomas,
My understanding is the security built into .NET prevents this from
happening for largely the opposite reason then you are wanting it to happen.

In that with .NET security I cannot introduce an assembly that reduces the
security of the standard assemblies.

I cannot replace the System.Data.OleDb.OleDbCommand with an object that will
bypass the System.Data.OleDb.OleDbPermission permissions.

For a good starting point on articles on .NET security see:
http://msdn.microsoft.com/library/de...rksecurity.asp

Hope this helps
Jay

"Thomas Christmann" <th***************@online.de> wrote in message
news:5t***************************@40tude.net...

Hi!

I have a rather special question here. I'd like to write a wrapper
for a .NET assembly, and register that on my server so that the people on
my server call my assembly instead of the standard .NET assembly. Reason
is that I want to include some additional security checks in my assembly,
to prevent everybody from the calling the .NET assembly unchecked. So,
writing the wrapper is no problem, but I'm not sure how/if it is possible
to register my assembly on the server to be called *instead* of the
original assembly, using the original name. So, e.g. if the customer
creates an instance of System.Data.OleDb.OleDbCommand, I want an instance
from *my* System.Data.OleDb.OleDbCommand to be created (that in turn will
eventually create an instance of the real System.Data.OleDb.OleDbCommand,
granted the caller will pass my security checks). I don't want the customer to have to call something like System.Data.MyCustomOleDb.OleDbCommand,
since my class won't be available at their client computer when they create their apps, and it will be just easier otherwise.
I remember that achieving the above was no probelm with COM, but is it
possible in .NET as well?

TIA,

Thomas

[Thomas Christmann]

> I cannot replace the System.Data.OleDb.OleDbCommand with an object that will

bypass the System.Data.OleDb.OleDbPermission permissions.

Is there a good reason why not? Is it strictly not possible, or is it just
that OleDbPermissions relies on OleDbCommand being there, and being named
like that? In which case I could maybe replace OleDbCommand as well...

Maybe I should clear this up a bit: My aim is not to really replace OleDb
completely, I just would like to have all ASP.NET calls to everything below
System.Data.OleDb to be "routed" to *my* version of System.Data.OleDb.*
(which would act like a proxy to the real System.Data.OleDb). So, I don't
want to replace it, I just want to "hijack" it's name, system wide. In COM
this was easily acheived by just going to the registry and replacing the
value of the ProgID key of the old component with something like
"component.old" and giving your new component the original name of the old
component, in the same key, respectively. The new component would then
reference the old one by calling component.old, and system wide, the new
component would replace the old component (and would act like a proxy).
THIS I would like to achieve with .NET assemblies. Possible? If no, why
not? :-)

Thanks,

Thomas

[Thomas Christmann]

> I cannot replace the System.Data.OleDb.OleDbCommand with an object that will

bypass the System.Data.OleDb.OleDbPermission permissions.

Is there a good reason why not? Is it strictly not possible, or is it just
that OleDbPermissions relies on OleDbCommand being there, and being named
like that? In which case I could maybe replace OleDbCommand as well...

Maybe I should clear this up a bit: My aim is not to really replace OleDb
completely, I just would like to have all ASP.NET calls to everything below
System.Data.OleDb to be "routed" to *my* version of System.Data.OleDb.*
(which would act like a proxy to the real System.Data.OleDb). So, I don't
want to replace it, I just want to "hijack" it's name, system wide. In COM
this was easily acheived by just going to the registry and replacing the
value of the ProgID key of the old component with something like
"component.old" and giving your new component the original name of the old
component, in the same key, respectively. The new component would then
reference the old one by calling component.old, and system wide, the new
component would replace the old component (and would act like a proxy).
THIS I would like to achieve with .NET assemblies. Possible? If no, why
not? :-)

Thanks,

Thomas

[JD]

> Is there a good reason why not? Is it strictly not possible, or is it just

that OleDbPermissions relies on OleDbCommand being there, and being named
like that? In which case I could maybe replace OleDbCommand as well...
Security.

If someone was using an existing method in OleDB type that did this:

Begin SomeMethod
Demand Permissions
If Demand OK Then do secure action
End SomeMethod

Now you replace the assembly and SomeMethod with your own version:

Begin SomeMethod
do secure action
End SomeMethod

This is a security breach, no?

Not to mention when .NET applications are built, the resulting manifest
contains which assemblies its dependent upon, along with versions, along
with public key tokens.

The better thing to do is have your clients rely on the standard data
provider interfaces instead, use the factory pattern which can be configured
to pass back your objects or OleDB objects.
"Thomas Christmann" <th***************@online.de> wrote in message
news:9n****************************@40tude.net...

I cannot replace the System.Data.OleDb.OleDbCommand with an object that will bypass the System.Data.OleDb.OleDbPermission permissions.

Is there a good reason why not? Is it strictly not possible, or is it just
that OleDbPermissions relies on OleDbCommand being there, and being named
like that? In which case I could maybe replace OleDbCommand as well...

Maybe I should clear this up a bit: My aim is not to really replace OleDb
completely, I just would like to have all ASP.NET calls to everything

below System.Data.OleDb to be "routed" to *my* version of System.Data.OleDb.*
(which would act like a proxy to the real System.Data.OleDb). So, I don't
want to replace it, I just want to "hijack" it's name, system wide. In COM
this was easily acheived by just going to the registry and replacing the
value of the ProgID key of the old component with something like
"component.old" and giving your new component the original name of the old
component, in the same key, respectively. The new component would then
reference the old one by calling component.old, and system wide, the new
component would replace the old component (and would act like a proxy).
THIS I would like to achieve with .NET assemblies. Possible? If no, why
not? :-)

Thanks,

Thomas

[Thomas Christmann]

> Begin SomeMethod

Demand Permissions
If Demand OK Then do secure action
End SomeMethod

Now you replace the assembly and SomeMethod with your own version:

Begin SomeMethod
do secure action
End SomeMethod

This is a security breach, no?
Well, yes, I understand this would be a security breach, but I was looking
more for why it isn't allowed. Technically, I mean. What prevents it? CAS?
Something deep inside the assembly itself?
Not to mention when .NET applications are built, the resulting manifest
contains which assemblies its dependent upon, along with versions, along
with public key tokens.
Ah okay, key tokens, that I understand. Okay, thats a reason it wouldn't
work, true.
The better thing to do is have your clients rely on the standard data
provider interfaces instead, use the factory pattern which can be configured
to pass back your objects or OleDB objects.

Well, I can't really use OleDB. See, the scenario is that I host ASP.NET
applications on my server, but I don't want to run full trust.
Unfortunately OleDB only works with full trust. So, an article on the MS
website explained that you could write a wrapper around some OleDB
functionality, then register that in gac (to be run under full trust), and
call the (full trusted, globally available) assembly from ASP.NET
applications running under partial trust. Now, this works just fine, I bet,
but the ultimate goal would be to give my clients the convinience of not
having to use my stuff, but the MS stuff instead (from their point of
view).

Ciao,

Thomas

[Jay B. Harlow [MVP - Outlook]]

Thomas,
I'm not sure what the full reason is. Nor if you really can or cannot do
it.

I believe you missed my point, one very good reason to prevent it is
security, as JD explained, and I attempted to explain. What you are
attempting to do is how one might bypass security.

Just a thought
Jay

"Thomas Christmann" <th***************@online.de> wrote in message
news:9n****************************@40tude.net...

I cannot replace the System.Data.OleDb.OleDbCommand with an object that will bypass the System.Data.OleDb.OleDbPermission permissions.
Is there a good reason why not? Is it strictly not possible, or is it just
that OleDbPermissions relies on OleDbCommand being there, and being named
like that? In which case I could maybe replace OleDbCommand as well...

Maybe I should clear this up a bit: My aim is not to really replace OleDb
completely, I just would like to have all ASP.NET calls to everything

below System.Data.OleDb to be "routed" to *my* version of System.Data.OleDb.*
(which would act like a proxy to the real System.Data.OleDb). So, I don't
want to replace it, I just want to "hijack" it's name, system wide. In COM
this was easily acheived by just going to the registry and replacing the
value of the ProgID key of the old component with something like
"component.old" and giving your new component the original name of the old
component, in the same key, respectively. The new component would then
reference the old one by calling component.old, and system wide, the new
component would replace the old component (and would act like a proxy).
THIS I would like to achieve with .NET assemblies. Possible? If no, why
not? :-)

Thanks,

Thomas

[Jay B. Harlow [MVP - Outlook]]

Thomas,
Oh! another reason to prevent it, your assembly could introduce
instabilities in the framework.

I can here the calls to MS Support now. I'm using OleDbCOmmand on my machine
and it works fine, I deploy it to my ISP and I get a Argument Out Of Range
exception. (as your wrapper had a slight flaw in it, that you did not
catch...)

If you find it documented how to do it, I hope you will post here.

Just another thought
Jay

"Thomas Christmann" <th***************@online.de> wrote in message
news:9n****************************@40tude.net...

I cannot replace the System.Data.OleDb.OleDbCommand with an object that will bypass the System.Data.OleDb.OleDbPermission permissions.
Is there a good reason why not? Is it strictly not possible, or is it just
that OleDbPermissions relies on OleDbCommand being there, and being named
like that? In which case I could maybe replace OleDbCommand as well...

Maybe I should clear this up a bit: My aim is not to really replace OleDb
completely, I just would like to have all ASP.NET calls to everything

below System.Data.OleDb to be "routed" to *my* version of System.Data.OleDb.*
(which would act like a proxy to the real System.Data.OleDb). So, I don't
want to replace it, I just want to "hijack" it's name, system wide. In COM
this was easily acheived by just going to the registry and replacing the
value of the ProgID key of the old component with something like
"component.old" and giving your new component the original name of the old
component, in the same key, respectively. The new component would then
reference the old one by calling component.old, and system wide, the new
component would replace the old component (and would act like a proxy).
THIS I would like to achieve with .NET assemblies. Possible? If no, why
not? :-)

Thanks,

Thomas

[JD]

> What prevents it? CAS?

Yep.

Unfortunately OleDB only works with full trust.
No kidding. I never realized this or ran into a problem because of it.

"Thomas Christmann" <th***************@online.de> wrote in message
news:53******************************@40tude.net.. .

Begin SomeMethod
Demand Permissions
If Demand OK Then do secure action
End SomeMethod

Now you replace the assembly and SomeMethod with your own version:

Begin SomeMethod
do secure action
End SomeMethod

This is a security breach, no?

Well, yes, I understand this would be a security breach, but I was looking
more for why it isn't allowed. Technically, I mean. What prevents it? CAS?
Something deep inside the assembly itself?

Not to mention when .NET applications are built, the resulting manifest
contains which assemblies its dependent upon, along with versions, along
with public key tokens.

Ah okay, key tokens, that I understand. Okay, thats a reason it wouldn't
work, true.

The better thing to do is have your clients rely on the standard data
provider interfaces instead, use the factory pattern which can be configured to pass back your objects or OleDB objects.

Well, I can't really use OleDB. See, the scenario is that I host ASP.NET
applications on my server, but I don't want to run full trust.
Unfortunately OleDB only works with full trust. So, an article on the MS
website explained that you could write a wrapper around some OleDB
functionality, then register that in gac (to be run under full trust), and
call the (full trusted, globally available) assembly from ASP.NET
applications running under partial trust. Now, this works just fine, I

bet, but the ultimate goal would be to give my clients the convinience of not
having to use my stuff, but the MS stuff instead (from their point of
view).

Ciao,

Thomas

[Thomas Christmann]

>> What prevents it? CAS?

Yep.

Can't I change the CAS policy that prevents it then? (apart from still
having the token problem, of course).

Unfortunately OleDB only works with full trust.

No kidding. I never realized this or ran into a problem because of it.

Just try to set your ASP.NET trust level to anything else then full, and
try to access an Access Database. No go. This is one of the main problems
that hosters have when offering ASP.NET (despite the ones that don't even
know what a trust level is *g*).

Ciao,

Thomas

[Thomas Christmann]

Hi!

As for why I try to do this, see my first reply to JD above. In short,
I need a wrapper for OleDB to make it work from ASP.NET in a scenario
that doesn't have full trust.

Thomas,
Oh! another reason to prevent it, your assembly could introduce
instabilities in the framework.
Well, yes. Any code you write can introduce instabilities, you just have
to make sure it written properly. That doesn't prevent me from coding
though.
I can here the calls to MS Support now. I'm using OleDbCOmmand on my machine
and it works fine, I deploy it to my ISP and I get a Argument Out Of Range
exception. (as your wrapper had a slight flaw in it, that you did not
catch...)
Flaws? In my code?! Just kidding ;-) Sure, it can happen, but it can also
happen with any other piece of code I write, that's in the nature of
things, and that's what a thorough testing phase is for. Also, my customers
wouldn't have OleDB without the wrapper at all, so even if it would have
some flaws at the beginning, they can at least use Access databases at all.
Also, believe me, customers call the ISP first, then a second and a third
time, and only in the las resort, MS Support :-)
If you find it documented how to do it, I hope you will post here.

If I will (can) do it, I will document it and post it. It's not documented
anywhere else yet, AFAIK.

Ciao,

Thomas

[JD]

> Can't I change the CAS policy that prevents it then? (apart from still

having the token problem, of course).

Nope. The OLE DB requires full-trust callers. Anyone calling into OLE DB
without full trust won't have the correct rights. You may have already read
the link below.

http://msdn.microsoft.com/library/de...l/THCMCh09.asp

They suggest sandboxing which wraps the OLE DB access code, give the wrapper
full trust so OLE DB works, but the wrapper doesn't require callers to have
full trust. Essentially you are loosening up OLE DB full trust requirement
with your wrapper. This doesn't really help in your case though.

"Thomas Christmann" <th***************@online.de> wrote in message
news:h0****************************@40tude.net...

What prevents it? CAS?

Yep.

Can't I change the CAS policy that prevents it then? (apart from still
having the token problem, of course).

Unfortunately OleDB only works with full trust.

No kidding. I never realized this or ran into a problem because of it.

Just try to set your ASP.NET trust level to anything else then full, and
try to access an Access Database. No go. This is one of the main problems
that hosters have when offering ASP.NET (despite the ones that don't even
know what a trust level is *g*).

Ciao,

Thomas

[Thomas Christmann]

Hi!

http://msdn.microsoft.com/library/de...l/THCMCh09.asp

They suggest sandboxing which wraps the OLE DB access code, give the wrapper
full trust so OLE DB works, but the wrapper doesn't require callers to have
full trust. Essentially you are loosening up OLE DB full trust requirement
with your wrapper. This doesn't really help in your case though.

Well, yes, that's the article I read, and that's exactly what I'm trying to
do. But instead of sandboxing the DB calls from my App (like having an
assembly that takes some parameters, makes DB queries and resturns
strings), I was thinking about "sandboxing" the whole OleDb Namespace.
I know this will be incredibly hard to begin with, but another problem with
doing this, is that if applications have to use my new Namespace instead of
the old OleDb, I will run in all kinds of troubles because people tend to
develop their stuff at home (without my new namespace) and then upload to
my server (with my new namespace). So I either have the choice of making
the server believe my new namespace IS the old namespace (that's what I was
asking originally), or giving the client my new namespace, and make sure
that it integrates and works with the .NET GUI.

But yeah, I see this is getting harder and harder to do. Maybe one should
just wait for the next release of the .NET framework, where OleDb is
rumored to allow partially trusted callers...

Thanks,

Thomas

[JD]

Here is the only thing I could think of. You could publish your OLE DB
wrapper to your clients, available for download. Sign it with a certificate,
version it, sign it, the whole nine yards. Explain to your customers its a
work around for the limitation in OLE DB, even providing them the links
outlining the limitation. Its definately not perfect...

"Thomas Christmann" <th***************@online.de> wrote in message
news:1i*****************************@40tude.net...

Hi!

http://msdn.microsoft.com/library/de...us/dnnetsec/ht
ml/THCMCh09.asp
They suggest sandboxing which wraps the OLE DB access code, give the wrapper full trust so OLE DB works, but the wrapper doesn't require callers to have full trust. Essentially you are loosening up OLE DB full trust requirement with your wrapper. This doesn't really help in your case though.
Well, yes, that's the article I read, and that's exactly what I'm trying

to do. But instead of sandboxing the DB calls from my App (like having an
assembly that takes some parameters, makes DB queries and resturns
strings), I was thinking about "sandboxing" the whole OleDb Namespace.
I know this will be incredibly hard to begin with, but another problem with doing this, is that if applications have to use my new Namespace instead of the old OleDb, I will run in all kinds of troubles because people tend to
develop their stuff at home (without my new namespace) and then upload to
my server (with my new namespace). So I either have the choice of making
the server believe my new namespace IS the old namespace (that's what I was asking originally), or giving the client my new namespace, and make sure
that it integrates and works with the .NET GUI.

But yeah, I see this is getting harder and harder to do. Maybe one should
just wait for the next release of the .NET framework, where OleDb is
rumored to allow partially trusted callers...

Thanks,

Thomas

[Thomas Christmann]

Am Tue, 4 May 2004 09:57:16 -0400 schrieb JD:

Here is the only thing I could think of. You could publish your OLE DB
wrapper to your clients, available for download. Sign it with a certificate,
version it, sign it, the whole nine yards. Explain to your customers its a
work around for the limitation in OLE DB, even providing them the links
outlining the limitation. Its definately not perfect...

Yep, that might be the only way. Ah well, better then nothing.

Thanks for the help,

Thomas