caspol -resolveperm

[Brian Gideon]

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?

 

[bruce barker]

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

-- bruce (sqlwork.com)

 

[Brian Gideon]

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."

 

[Alvin Bruney [ASP.NET MVP]]

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]

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.

 

[Alvin Bruney [ASP.NET MVP]]

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]

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.