Time for a quick break from managed hosting.  I've been asked several times on this blog and in the newsgroups about the FullTrust list that the CLR keeps.  What is it, and why does it exist?

The reason for the list is due to a problem that exists when evaluating policy.  Since all security policy objects are managed code, they're all subject to the CAS system just like any other managed code.  This simple fact results in our need for a FullTrust list.  In order to demonstrate that, lets walk through an example of running some code off of a network share.

When I load the assembly, the CLR must determine its grant set.  So it loads the security policy off of the disk, and deserializes it into security objects.  Among the objects it's going to have to create are various membership conditions, code groups, and permissions.  In order to create these objects, the CLR will have to load the assemblies that contain them.  By default, this is going to include mscorlib, System.dll, and some others.  No problem so far.  However, when loading these other assemblies, they're going to need to get a grant set.  In order to determine that grant set, the CLR is going to have to evaluate the security policy.  And when it tries to create the policy (say for System.dll), it's going to have to load all the assemblies that contain the various security objects.

As you can see from the example, without some modification to the default CAS system, we're in a never ending cycle between loading assemblies that contain security objects and granting them policy. ... enter the FullTrust list.  All assemblies that contain security objects must be on the FullTrust list.  Once they're on that list, the security system no longer needs to evaluate policy in order to determine their grant set.  And that breaks the infinite cycle, allowing for grant sets to be determined.

So it turns out that the FullTrust list is used to bypass the security policy to determine the grant set of assemblies that contain objects in that policy.  Whenever you create a custom permission, code group, evidence, or membership condition, you need to make sure to register the assembly containing those classes on the FullTrust list.  However, you should not just register any assembly there that you want to have FullTrust, for non-policy assemblies, you should stick within the CAS system and create matching code groups that will grant the trust that you need.