running dll from a network share

20 Apr 2005 3:34 PM

Bob Weiner

I am having code access security problems executing a dll from a remote
computer.

I developed a Hello World solution using C# on a network share for testing.
It consists of one dll containing two public methods. The first is sayHi()
which displays a hello message to the console, and the other is storeHi()
which writes the message to a file. The solution also contains a console
application which loads/calls the dll.

If the console app only calls the sayHi() method, the dll executes properly.
If it attempts to call storeHi() it generates a
System.Security.Permissions.FileIOPermission error.

To get around this I tried giving the dll a strong name by including
[assembly: AssemblyKeyFile(@"..\..\..\bob.snk")]
in the AssemblyInfo.cs file. This prevented the code from running at all
(because the assembly could not find the snk file after it loaded on the
local machine?)

I also tried creating a code group in the My_Computer_Zone and
LocalIntranet_Zone and granting FullTrust based on a Hash of the dll. That
didn't work either; I have no idea why not.

What do I have to do to load a dll from a network share and execute it
locally with FullTrust?

thanks,
bob

20 Apr 2005 10:22 PM

swat

The FileIOPermission error is generated because you do not have
permission to write to the file. Where is the file being written to
located? On the share? If so, did you set the necessary permissions on
the share to allow access to the share as well as the file?

CAS runs on top of the OS. If the OS denies access to a file, setting
FullTrust through CAS will not override the permissions the OS grants.

21 Apr 2005 2:07 AM

Joe Kaplan (MVP - ADSI)

This is not correct. He has a CAS problem, not a Windows security problem.
You get an UnauthorizedAccessException if you are denied access due to ACL
issues.

If the assembly actually is signed with a strong name, then the modification
to the intranet zone policy with the strong name key hash should have
worked. Nicole is much better at diagnosing these issues than I am, so
hopefully she'll bounce in and fix it.

Typically, you wouldn't want to grant Full Trust if you can avoid it. It
would be much better to grant only the permissions you really need.
However, starting with Full Trust is sometimes useful for getting something
working.

Joe K.

Show quoteHide quote

"swat" <loka_1***@yahoo.com> wrote in message
news:1114035753.794486.91160@g14g2000cwa.googlegroups.com...
> The FileIOPermission error is generated because you do not have
> permission to write to the file. Where is the file being written to
> located? On the share? If so, did you set the necessary permissions on
> the share to allow access to the share as well as the file?
>
> CAS runs on top of the OS. If the OS denies access to a file, setting
> FullTrust through CAS will not override the permissions the OS grants.
>

21 Apr 2005 11:17 AM

Nicole Calinoiu

"Bob Weiner" <b**@engr.uconn.edu> wrote in message
news:%23L%23Jn5bRFHA.1500@TK2MSFTNGP09.phx.gbl...

<snip>

> I also tried creating a code group in the My_Computer_Zone and
> LocalIntranet_Zone and granting FullTrust based on a Hash of the dll.
> That didn't work either; I have no idea why not.

I'm guessing that both your exe (the console app) and the dll are being run
from the same network share. If so, the exe is also being denied
FileIOPermission based on its location in the intranet zone. When the code
attempts to write to a file, a full demand for FileIOPermission is made,
which means that all code on the call stack (which includes both your dll
and your exe) must have the demanded permission. Adding a code group to the
local intranet zone that grants unrestricted FileIOPermission (or, even
better, just permission to the target file if has a constant path) to the
console app assembly based on its hash should probably resolve the problem.

Show quoteHide quote

>
>
> What do I have to do to load a dll from a network share and execute it
> locally with FullTrust?
>
> thanks,
> bob
>

21 Apr 2005 8:08 PM

Bob Weiner

Yes. I think that was it.

I did a reset on the machine level to clear all the accumulated garbage so
I'm not sure what the permission status was before. I did not realize that
the exe restrictions would be inherited by the dll so didn't consciously
grant those permissions. It does work now so I think you hit it on the
head!

I plan on playing around with them more now that I can make it work to get a
better feel for how they work.

Thanks to all that responded.

bob

Show quoteHide quote

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:eWgw0TmRFHA.3560@TK2MSFTNGP14.phx.gbl...
> "Bob Weiner" <b**@engr.uconn.edu> wrote in message
> news:%23L%23Jn5bRFHA.1500@TK2MSFTNGP09.phx.gbl...
> <snip>
>> I also tried creating a code group in the My_Computer_Zone and
>> LocalIntranet_Zone and granting FullTrust based on a Hash of the dll.
>> That didn't work either; I have no idea why not.
>
> I'm guessing that both your exe (the console app) and the dll are being
> run from the same network share. If so, the exe is also being denied
> FileIOPermission based on its location in the intranet zone. When the
> code attempts to write to a file, a full demand for FileIOPermission is
> made, which means that all code on the call stack (which includes both
> your dll and your exe) must have the demanded permission. Adding a code
> group to the local intranet zone that grants unrestricted FileIOPermission
> (or, even better, just permission to the target file if has a constant
> path) to the console app assembly based on its hash should probably
> resolve the problem.
>
>
>>
>>
>> What do I have to do to load a dll from a network share and execute it
>> locally with FullTrust?
>>
>> thanks,
>> bob
>>
>
>

22 Apr 2005 11:12 AM

Nicole Calinoiu

"Bob Weiner" <b**@engr.uconn.edu> wrote in message
news:eI1OZ3qRFHA.3664@TK2MSFTNGP15.phx.gbl...
> Yes. I think that was it.
>
> I did a reset on the machine level to clear all the accumulated garbage so
> I'm not sure what the permission status was before. I did not realize
> that the exe restrictions would be inherited by the dll

It's not really an issue of inheritance. If you're curious about how the
permission demands work, a good place to start might be
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconIntroductionToCodeAccessSecurity.asp.

Show quoteHide quote

> so didn't consciously grant those permissions. It does work now so I
> think you hit it on the head!
>
> I plan on playing around with them more now that I can make it work to get
> a better feel for how they work.
>
> Thanks to all that responded.
>
> bob
>
>
>
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:eWgw0TmRFHA.3560@TK2MSFTNGP14.phx.gbl...
>> "Bob Weiner" <b**@engr.uconn.edu> wrote in message
>> news:%23L%23Jn5bRFHA.1500@TK2MSFTNGP09.phx.gbl...
>> <snip>
>>> I also tried creating a code group in the My_Computer_Zone and
>>> LocalIntranet_Zone and granting FullTrust based on a Hash of the dll.
>>> That didn't work either; I have no idea why not.
>>
>> I'm guessing that both your exe (the console app) and the dll are being
>> run from the same network share. If so, the exe is also being denied
>> FileIOPermission based on its location in the intranet zone. When the
>> code attempts to write to a file, a full demand for FileIOPermission is
>> made, which means that all code on the call stack (which includes both
>> your dll and your exe) must have the demanded permission. Adding a code
>> group to the local intranet zone that grants unrestricted
>> FileIOPermission (or, even better, just permission to the target file if
>> has a constant path) to the console app assembly based on its hash should
>> probably resolve the problem.
>>
>>
>>>
>>>
>>> What do I have to do to load a dll from a network share and execute it
>>> locally with FullTrust?
>>>
>>> thanks,
>>> bob
>>>
>>
>>
>
>

Thread options