I obviously need some education on how caspol -resolveperm works. I
was having a problem with my ASP.NET application throwing a
SecurityException from System.Web.Extensions.dll. So I tried:

caspol -all -resolveperm "C:\<path>\System.Web.Extensions.dll"

And I got the following output.

Resolving permissions for level = Enterprise
Resolving permissions for level = Machine
Resolving permissions for level = User

Grant =
<PermissionSet class="System.Security.PermissionSet"
version="1"
Unrestricted="true"/>

Success

Yet, the dll definitely will not execute. When I moved the dll to the
GAC it would start executing except that I would get another
SecurityException on another dll. The output of caspol stayed the
same no matter where the dll resided. By the way, adding <trust
level="Full" /> to my Web.config got everything going.

Why would caspol tell me that access is unrestricted to the dll when
it clearly was restricted? Does it have something to do with the user
caspol is running as? How do I get caspol to resolve permission sets
from the context of ASP.NET?

caspol -resolveperm shows what permissions the assembly will be granted, not
what it requires to run.

-- bruce (sqlwork.com)


"Brian Gideon" wrote:

> I obviously need some education on how caspol -resolveperm works. I
> was having a problem with my ASP.NET application throwing a
> SecurityException from System.Web.Extensions.dll. So I tried:
>
> caspol -all -resolveperm "C:\<path>\System.Web.Extensions.dll"
>
> And I got the following output.
>
> Resolving permissions for level = Enterprise
> Resolving permissions for level = Machine
> Resolving permissions for level = User
>
> Grant =
> <PermissionSet class="System.Security.PermissionSet"
> version="1"
> Unrestricted="true"/>
>
> Success
>
> Yet, the dll definitely will not execute. When I moved the dll to the
> GAC it would start executing except that I would get another
> SecurityException on another dll. The output of caspol stayed the
> same no matter where the dll resided. By the way, adding <trust
> level="Full" /> to my Web.config got everything going.
>
> Why would caspol tell me that access is unrestricted to the dll when
> it clearly was restricted? Does it have something to do with the user
> caspol is running as? How do I get caspol to resolve permission sets
> from the context of ASP.NET?
>
>

On Aug 21, 10:54*am, bruce barker
<brucebar...@discussions.microsoft.com> wrote:
> caspol -resolveperm shows what permissions the assembly will be granted, not
> what it requires to run.
>

Thanks for the response.

That seems to conflict with the documentation at <http://
msdn.microsoft.com/en-us/library/tx1dts55.aspx> (at least my
interpretation of it anyway).

In reference to caspol –all –resolveperm assembly-file:

"Determine whether the assembly has the right to execute by checking
whether the execution flag is set in the SecurityPermission class. If
the assembly has execution rights, the security permission set will be
unrestricted, or the flags attribute will include the execution flag."

This resolveperm call will likely give you incorrect results because you are
pointing to a file on disk which should run with full trust or unrestricted
and be sourced from a different zone. However, your web application may be
calling the dll through a virtual path from the server http://server/my.dll
for instance.

Another thing is that you haven't fixed your issue at all, in fact, you've
made it worse. consider this: you try to open the front door of your house
with a key and the key is giving problems. Your fix is simply to remove the
door ensuring that the key problem goes away right? Now you have a bigger
problem. I think you should fix the lock instead of removing the door. it's
there for a reason.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Download OWC Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $15.00
Need a free copy of VSTS 2008 w/ MSDN Premium?
http://msmvps.com/blogs/alvin/Default.aspx
-------------------------------------------------------


"Brian Gideon" <(E-Mail Removed)> wrote in message
news:07d8c1db-3163-40f9-8aec-(E-Mail Removed)...
> I obviously need some education on how caspol -resolveperm works. I
> was having a problem with my ASP.NET application throwing a
> SecurityException from System.Web.Extensions.dll. So I tried:
>
> caspol -all -resolveperm "C:\<path>\System.Web.Extensions.dll"
>
> And I got the following output.
>
> Resolving permissions for level = Enterprise
> Resolving permissions for level = Machine
> Resolving permissions for level = User
>
> Grant =
> <PermissionSet class="System.Security.PermissionSet"
> version="1"
> Unrestricted="true"/>
>
> Success
>
> Yet, the dll definitely will not execute. When I moved the dll to the
> GAC it would start executing except that I would get another
> SecurityException on another dll. The output of caspol stayed the
> same no matter where the dll resided. By the way, adding <trust
> level="Full" /> to my Web.config got everything going.
>
> Why would caspol tell me that access is unrestricted to the dll when
> it clearly was restricted? Does it have something to do with the user
> caspol is running as? How do I get caspol to resolve permission sets
> from the context of ASP.NET?
>

On Aug 21, 7:29*pm, "Alvin Bruney [ASP.NET MVP]" <vapor dan using hot
male spam filter> wrote:
> This resolveperm call will likely give you incorrect results because you are
> pointing to a file on disk which should run with full trust or unrestricted
> and be sourced from a different zone. However, your web application may be
> calling the dll through a virtual path from the serverhttp://server/my.dll
> for instance.

I figured that might have something to do with it. That's unfortunate
really because I'd like to do a resolvegroup on that dll as well to
assist in troubleshooting. I guess I'll have to go through the config
files manually.

>
> Another thing is that you haven't fixed your issue at all, in fact, you've
> made it worse. consider this: you try to open the front door of your house
> with a key and the key is giving problems. Your fix is simply to remove the
> door ensuring that the key problem goes away right? Now you have a bigger
> problem. I think you should fix the lock instead of removing the door. it's
> there for a reason.
>

That is an enlightening analogy.

What you should do is first revert the config permission elevation and cause
the error to be generated. Then, once you have the error generated, turn
caspolicy off on the machine and see if you get the error. If you do get the
issue, you have another issue masquerading as a security issue since no
security policy is running on the machine.

If you do not get the error, you can simply create a cas policy for the
particular permission shown in the error message dialog. Create your policy
using the graphical interface to the caspol command line tool, mscorcfg.msc.
By the way, I always us mscorcfg.msc to resolve permissions on an assembly
because it knows exactly how to find and call the dll with the right
options.

CAS policies are not that hard to create (an hour or 2 of trial and error
for instance) and once you understand what's going on, these issues will
never get the better of you again.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Download OWC Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $15.00
Need a free copy of VSTS 2008 w/ MSDN Premium?
http://msmvps.com/blogs/alvin/Default.aspx
-------------------------------------------------------


"Brian Gideon" <(E-Mail Removed)> wrote in message
news:95c74442-dc75-4774-b56e-(E-Mail Removed)...
> On Aug 21, 7:29 pm, "Alvin Bruney [ASP.NET MVP]" <vapor dan using hot
> male spam filter> wrote:
>> This resolveperm call will likely give you incorrect results because you
>> are
>> pointing to a file on disk which should run with full trust or
>> unrestricted
>> and be sourced from a different zone. However, your web application may
>> be
>> calling the dll through a virtual path from the
>> serverhttp://server/my.dll
>> for instance.
>
> I figured that might have something to do with it. That's unfortunate
> really because I'd like to do a resolvegroup on that dll as well to
> assist in troubleshooting. I guess I'll have to go through the config
> files manually.
>
>>
>> Another thing is that you haven't fixed your issue at all, in fact,
>> you've
>> made it worse. consider this: you try to open the front door of your
>> house
>> with a key and the key is giving problems. Your fix is simply to remove
>> the
>> door ensuring that the key problem goes away right? Now you have a bigger
>> problem. I think you should fix the lock instead of removing the door.
>> it's
>> there for a reason.
>>
>
> That is an enlightening analogy.

On Aug 22, 5:06*pm, "Alvin Bruney [ASP.NET MVP]" <vapor dan using hot
male spam filter> wrote:
> What you should do is first revert the config permission elevation and cause
> the error to be generated. Then, once you have the error generated, turn
> caspolicy off on the machine and see if you get the error. If you do get the
> issue, you have another issue masquerading as a security issue since no
> security policy is running on the machine.
>
> If you do not get the error, you can simply create a cas policy for the
> particular permission shown in the error message dialog. Create your policy
> using the graphical interface to the caspol command line tool, mscorcfg.msc.
> By the way, I always us mscorcfg.msc to resolve permissions on an assembly
> because it knows exactly how to find and call the dll with the right
> options.
>
> CAS policies are not that hard to create (an hour or 2 of trial and error
> for instance) and once you understand what's going on, these issues will
> never get the better of you again.
>

Thanks for the tips Alvin. I'll give those ideas a try and see what
happens. I think I'll have to copy mscorcfg.msc and it's dependencies
onto the server in question. I believe it only comes with the
SDK...correct? It shouldn't be an issue either way.