21.3 Requesting Permissions Using Imperative Security Requests

You want to request security permissions while a method is executing.

Technique

The technique is to instantiate an instance of the appropriate security class and use methods on that instance to make the security request. For example, suppose a method is about to use isolated storage in a way that you are certain will be safe, no matter how the currently executing method is called, so you want to assert the isolated file storage permission:

 void AccessIsolatedStorageSafely() {         IsolatedStorageFilePermission perm =              new IsolatedStorageFilePermission(PermissionState.Unrestricted);         perm.Assert();         // code to access isolated storage safely goes here         // etc. 

On the other hand, suppose you want to prevent a method from being abused by malicious code that uses a file save dialog:

 void DontWantToUseFileDialogs() {         // up to this point we can use save file dialogs         FileDialogPermission dlgPerm = new FileDialogPermission(             FileDialogPermissionAccess.Save);         dlgPerm.Deny();         // from this point onwards we cannot use save file dialogs         // when method exits the deny will be cancelled and we can use file dialogs again } 

Table 21.4 lists the four main methods that you can use to control imperative security.

Table 21.4. Add a Title Here

Method	Effect
Demand()	Requests the indicated permission.
Assert()	Ensures that until the end of the currently executing method, the indicated permission will always be granted when requested , for example, by a call to Demand() , no matter whether code higher up the call stack has the permission. Note that there is a security permission that controls asserts, and an assembly must have both this permission and the permission you are seeking to assert if this call is to succeed.
Deny()	Ensures that until the end of the currently executing method, any request for the indicated permission will always be denied .
PermitOnly()	Similar to Deny() except that it causes any request for any permission other than the specified permission to be denied.

You'll notice that the Demand() method is somewhat unique because it is the method which is responsible for actually requesting that a permission be given to the executing code. The purpose of the other methods is to influence the result of calling Demand() if it is subsequently called within this method or any method called directly or indirectly from this method. In practice, you will rarely find you need to call Demand() directly because that is almost invariably handled by the classes in the framework class library. For example, if you try to use the System.IO.FileInfo class to open a file, that class "under the hood" demands the appropriate permissions before attempting to open the file.

None of these methods take any parameters. The specified permission is indicated by the object against which the methods are called. As far as the list of security permission classes is concerned , you can simply use Table 21.1 and knock Attribute off the name of each class. For example, corresponding to the attribute EnvironmentPermissionAttribute is a class EnvironmentPermission , which you can instantiate to define an environment permission, and then you call Assert() , Deny() , PermitOnly() , or Demand() against the EnvironmentPermission instance to control the permission. The security permission classes all derive from the class CodeAccessSecurity , which is the class that implements these four methods. Note that you need to check the documentation for details of the parameters to pass to each permission class constructor because it varies according to the nature of each permission.

Comments

Imperative security gives you a much finer degree of control than declarative security: You can place a call to set the security or request a permission at a precise point in a method, which means that, depending on the actual flow of execution, you have the option of not executing that permission if appropriate. For example, you might place the call to Demand() inside an if block. Alternatively, you can code imperative security so that the details of the permissions demanded are determined at runtime. On the other hand, there is no easy way for outside code to examine an assembly that uses imperative security to find out what security permissions will be required because there is no corresponding metadata to provide this information.