 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Security / April 2006Strange behaviour whith CAS UI tool ??
Dear all, I have a simple assembly that I use to test CAS. Without any CAS attribute to my assembly I am able to run the Evaluate Assembly option to identify current security. Then I add the followin to my asembly : <Assembly: PrintingPermission(SecurityAction.RequestMinimum)> I can still run the Evaluate Assembly option from CAS tool which return Unrestricted policy. So far so good Then I add the following : <Assembly: FileIOPermissionAttribute(SecurityAction.RequestOptional, Read:="C:\")> At this point I am not able to run anymore the Evaluate Assembly from CAS tool. It returns an error saying "Unable to load assembly" ?? Any idea what is going on and how to solve ? thnaks for your help regards serge Are you sure that adding the RequestOptional for FileIOPermission was the only change you made between the two evalutions? Did you perhaps also add a delay signed strong name signature? BTW, the "evaluate assembly" functionality offered by mscorcfg.msc only evalates an assembly's permissions under policy. It does not take into account assembly-level permission attributes, so the results should not differ as you alter the permission attributes. > Dear all, > [quoted text clipped - 21 lines] > regards > serge Yes this is the only change I made.... BTW, the "evaluate assembly" functionality offered by mscorcfg.msc only > evalates an assembly's permissions under policy. It does not take into > account assembly-level permission attributes, so the results should not > differ as you alter the permission attributes What do you means by this ?? > Are you sure that adding the RequestOptional for FileIOPermission was the > only change you made between the two evalutions? Did you perhaps also add a [quoted text clipped - 30 lines] > > regards > > serge > Yes this is the only change I made.... That's rather odd. Could you possibly try reproducing this with a new project? > BTW, the "evaluate assembly" functionality offered by mscorcfg.msc only >> evalates an assembly's permissions under policy. It does not take into >> account assembly-level permission attributes, so the results should not >> differ as you alter the permission attributes > > What do you means by this ?? The assembly-level permission attributes you are adding to your assembly (e.g.: <Assembly: FileIOPermissionAttribute(SecurityAction.RequestOptional, Read:="C:\")>) are completely ignored by the "evaluate assembly" functionality. No matter how many of these permission attributes you add, "evalute assembly" will continue to return the same result as long as the assembly continues to present the same evidence (broadly, location and digital signatures) and the CAS policy on the machine does not change. >> Are you sure that adding the RequestOptional for FileIOPermission was the >> only change you made between the two evalutions? Did you perhaps also [quoted text clipped - 32 lines] >> > regards >> > serge What is then the purpose of this Evaluate function then if it s not reflecting the real assembly permission ? PermView sounds more correct If I take a rela example like an assembly that I did know the source. I just been ask to use it. BUt then before that I would like to know if it use some security permission. For that let say that I run PermView. ok then I start to implement it and suddendly a security erro occurs in that assembly. How do you know with precision in which contect my assembly is running? Okay for sure it will run from My Computer zone as I run it locally but , could it run in more than one zone? > > Yes this is the only change I made.... > [quoted text clipped - 52 lines] > >> > regards > >> > serge > What is then the purpose of this Evaluate function then if it s not > reflecting the real assembly permission ? It is used to display the code group memberships and permissions of an assembly, as determined via CAS policy. This can be quite helpful when attempting to troubleshoot problems with permission grants, but it is not the same as attempting to determine the effective runtime permissions of an assembly. > PermView sounds more correct PermView displays the results of the assembly-level permission attributes. This has nothing to do with CAS policy on any given machine. If what you want to do is look at the attributes, then PermView would certainly be the better choice. > If I take a rela example like an assembly that I did know the source. I > just been ask to use it. BUt then before that I would like to know if it [quoted text clipped - 6 lines] > Okay for sure it will run from My Computer zone as I run it locally but , > could it run in more than one zone? If you ran it from another zone then, yes, it would be run from that zone. However, the source zone is not the only evidence that can be used when establishing CAS policy. >> > Yes this is the only change I made.... >> [quoted text clipped - 63 lines] >> >> > regards >> >> > serge Thanks a lot for your clarification nicole.. Sorry if question sounds basic, I just start to learn that part for my MCSD > > What is then the purpose of this Evaluate function then if it s not > > reflecting the real assembly permission ? [quoted text clipped - 94 lines] > >> >> > regards > >> >> > serge Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.