Determining the Granted Permissions
.gif "Important note") Important |
|---|
In the .NET Framework version 4, the common language runtime (CLR) is moving away from providing security policy for computers. Microsoft is recommending the use of Windows Software Restriction Policies as a replacement for CLR security policy. The information in this topic applies to the .NET Framework version 3.5 and earlier; it does not apply to version 4.0 and later. For more information about this and other changes, see Security Changes in the .NET Framework 4. |
For application domains, the granted permission set is simply the allowed permission set.
For assemblies, the common language runtime considers other factors at assembly-load time to determine the granted permission set. An assembly can contain declarative security requests that specify the permissions the code needs or wants to have. The following table describes the permission sets that code can request.
Permission set |
Description |
|---|---|
Required |
Specifies the minimum set of permissions the code must have to run. |
Optional |
Identifies permissions the code wants to have, in addition to the minimum set. This causes all permissions not identified in the minimum set or optional set to be implicitly refused. |
Refused |
Specifies permissions that should never be granted to the code. |
If all three permission requests are absent, the assembly is simply granted the permission set that policy allows. However, if at least one of the three permission requests is present, the runtime considers the requested permissions using the following process:
The runtime computes the allowed permissions for the assembly and insures that the assembly has permission to execute. If permission to execute is not present, the runtime throws a PolicyException and the code is not allowed to run.
The runtime determines whether the set of required permissions is a subset of the allowed permission set. If not, the runtime throws a PolicyException and the code is not allowed to run.
The runtime intersects the optional requested permissions with the allowed permission set. If optional permissions are not requested, then the optional PermissionSet is assumed to be FullTrust.
The runtime unions the result of step 3 with the minimum requested permissions.
Finally, the runtime subtracts any permissions that are refused from the result of step 4.