> Strong-named assemblies are documented as "...placing a LinkDemand for > FullTrust on every public or protected method on every > publicly accessible > class in the assembly". This means if an assembly doesn't refuse > FullTrust or doesn't use > AllowPartiallyTrustedCallersAttribute it cannot > be loaded from a not-fully-trusted zone.
My understanding of that quote is a bit different than yours. It's not saying that my strongly named assembly is implicitly granted full trust. It's saying that my strongly named assembly implicitly demands that my caller(s) are fully trusted (unless I use APTC to say otherwise). So that statement has nothing do with with my assembly's set of granted permissions, but the set of permissions my caller(s) will be required to have by default. There's a good write up on APCT here[1]. In particular, note that this quote (1st paragraph below the first gray code fragment): "By default, strongly named, **fully trusted** assemblies are given an implicit LinkDemand for FullTrust on every public and protected method of every publicly visible class." The **emphasis** is mine. IOW, being "strongly named" does not imply being "fully trusted". Those are orthogonal characteristics of an assembly. You can have one w/o the other. > And, just because an assembly does refuse some permission, > doesn't imply > the assembly won't be given full trust. Not that that has > any bearing on > this topic. I don't think that's correct. An assembly developer might use RequestRefuse to specifically not allow his/her code to run with full trust. But I'll admit to having not use RequestRefuse in actual practice, so my understanding of that point is an academic one. > So, getting back to StrongNameIdentityPermission; what is the > likelihood > that a) a strong-named assembly isn't running in full-trust and b) if > you've used StrongNamedIdentityPermission to specify a > specific assembly, > that you don't know whether that assembly is fully-trusted? I can't comment on likelihood. Re (a), it's easy enough to contemplate lots of no touch deployed apps that use strongly named assemblies of their own, and are running w/o full trust due to their deployment model. Re (b), again I think you're intermixing orthogonal issues. It's easy enough for me to envision using strong name identity permissions to place some restrictions on who calls me (subject to the new-in-2.0 characteristic that this no longer works if my caller is not fully trusted) w/o particularly knowing or caring at the time what their exact set of permissions is going to be. For example, at the time the identity requirement is made and implemented using a SNIP, the configured permissions of the calling assembly(ies) happens to be X. Those permissions should be allow to change from X to Y w/o negating the demand that said assembly(ies) still be strongly named with a particular keypair. > So, if > StrongNameIdentityPermission doesn't grant permission based > on the strong- > name (or part thereof) is it not redundant? > I don't understand that question. Assembly X uses a SNIP to request that the runtime require X's caller be strongly named with a particular key. It doesn't "grant" permissions to anything. -Mike Bear Canyon Consulting LLC http://www.bearcanyon.com http://www.pluralsight.com/mike [1] http://blogs.msdn.com/shawnfa/archive/2005/02/04/367390.aspx =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
