Determining the Security Rules for Your Assemblies – #14
June 3rd 2009 05:25 am
If you’ve followed this tip series you’ll know about two different kinds of security transparency, one present in CLR 2.0 and one in CLR 4.0. And you know that in CLR 4.0, you can decide to use the legacy transparency rules in CLR 2.0. And you know about this attribute called APTCA. Maybe a bit about permissions, too.
It can be really hard to keep all this information straight, so I’ve put together a flowchart to help you determine which transparency rules a particular assembly is using. I hope it’s useful!
As you can see, while the number of rules is not totally unmanageable, it can be difficult to keep them straight. There are also a few situations where two different paths lead to the same outcome. For example, your assembly can be fully critical when it is a level 2 assembly marked with the SecurityCriticalAttribute or when it is a level 1 assembly marked with the SecurityCriticalAttribute with SecurityCriticalScope.Everything. Keep in mind that even though the assembly is fully critical in both cases, the meaning of critical depends on the current level, level 1 or level 2. If you need a review, consult my previous tips on CLR v2 transparency and CLR v4 transparency.
Syndication
Jamebo responded on 05 Nov 2009 at 3:02 am #
I tested this case:
Assembly Full Trusted + Level 2 + SecurityCritical Attribute + APTCA. The assembly should be Full Critical.
But in your flow chart, it is transparent.
In MSDN, it said:
SecurityCritical with Level 2: All code that is introduced by types in this assembly is critical; all other code is transparent.
It seems all types and members are full critical. How to understand “all other code is transparent.”?
What the “all other code” means?
Thanks
-Jamebo
David DeWinter responded on 25 Nov 2009 at 9:55 pm #
Good call, Jamebo. I’ll update the flowchart when I find the Visio document. (I think it’s still on my work computer.)
By “all other code is transparent,” MSDN means overridden virtual methods and interface implementations, assuming those virtual methods and interfaces were defined in another assembly. The method must maintain the same transparency it did in the original assembly.