21.2 Requesting Permissions for a Class or Method Using Declarative Security

You want to use declarative security to indicate the security permissions required by a class or a method.

Technique

The technique is similar to that for applying security attributes to an assembly: You simply apply the same attributes to the relevant class or method instead. In this case, the security requests are processed the first time that the class or the method is used. However, the allowed security actions for a class or method are different. For a class or method, you can request the security actions in Table 21.3.

Table 21.3. SecurityAction Values for a Class or Method

Value	Meaning
LinkDemand	The immediate caller must have been granted the specified permission.
InheritanceDemand	Any class that derives from this class (or any method that overrides this method) must have the specified permission.
Demand	All assemblies in the call stack must have the specified permission. Use this request to indicate when a method or class needs to use a resource protected by a permission.
Assert	This method requires the specified permission and doesn't care whether other assemblies further up the call stack don't have it. Use this request when you know that a method or class has been tested and cannot be used to compromise the resource in question, no matter how its methods are invoked.
Deny	The specified permission should not be granted while executing code in this class or method. Use this request to prevent a method or class from being used by unscrupulous code to damage resources to which it would be allowed access but does not ever actually need to access.
PermitOnly	No permissions other than the specified permission should be granted while executing code in this class or method.

A couple of examples will illustrate this technique. The following code shows a method that needs permission to read the D:\ drive on the file system:

 [FileIOPermission(SecurityAction.Demand, Read=@"D:\")] public string [] ListDDriveFolders() { 

The next code is a class that often invokes unsafe code but has been thoroughly tested so we are sure it is sufficiently safe to assert this permission:

 [SecurityPermission(SecurityAction.Assert, UnmanagedCode=true)] public class SafeClass { 

Comments

When applying permissions to methods, you have a choice between using declarative and imperative security. The advantage of using declarative security is that it is often simpler to code and can lead to higher performance because you can perform the security checks when an assembly is loaded.

You also benefit from the extra information because the declarative security is visible through the assembly metadata. Note, however, that this benefit is not that significant for classes and methods because using that information requires an understanding of the classes and methods in an assembly. In addition, permview only displays security attributes applied to the assembly as a whole.

Declarative security does allow a couple of security actions that you cannot accomplish using imperative security. Imperative security does not contain any analogy to the link demand or the inheritance demand, so if you want to enforce those actions, you have no choice but to use declarative security.