Requesting Permissions
Requesting permissions is the way you let the runtime know what your code needs to be allowed to do. You request permissions for an assembly by placing attributes (declarative syntax) in the assembly scope of your code. When the assembly is created, the language compiler stores the requested permissions in the assembly manifest. At load time, the runtime examines the permission requests, and applies security policy rules to determine which permissions to grant to the assembly. Requests only influence the runtime to deny permissions to your code and never influence the runtime to give more permissions to your code. The local administration policy always has final control over the maximum permissions your code is granted.
Although your code does not have to request permissions in order to compile, there are important reasons your code should always request permissions:
Requesting permissions increases the likelihood that your code will run properly if it is allowed to execute. Code that request a minimal set of permissions will not run unless it receives those permissions. If you do not identify a minimum set of permissions, your code must gracefully handle any and all situations where not being granted some permission might prevent it from executing properly.
Requesting permissions helps ensure that your code is granted only the permissions it needs. If your code is not granted extra permissions, it cannot damage the resources protected by those extra permissions, even if it is exploited by malicious code or has bugs that can be leveraged to damage resources. You should request only those permissions that your code needs, and no more.
Requesting permissions lets administrators know the minimum permissions that your application needs so that they can adjust security policy accordingly. Administrators use the Permission View Tool (Permview.exe) to examine assemblies and set up security policy to issue required permissions. If you do not explicitly request the permissions that your application requires, the Permission View tool cannot return any information about the permissions that your application requires. If an administrator does not know this information, your application is difficult to administer.
Requesting permissions informs the runtime which permissions your application needs to function or specifically does not want. For example, if your application writes to the local hard disk without using isolated storage, your application must have FileIOPermission. If your code does not request FileIOPermission and the local security settings do not allow your application to have this permission, a security exception is raised when the application attempts to write to the disk. Even if the application can handle the exception, it will not be allowed to write to the disk. This behavior might be frustrating to users if your application is a text-editing program that they have been using for an extended period of time. On the other hand, if your application requests FileIOPermission and the local security settings do not allow your application to have FileIOPermission, the application will generate the exception when it starts and the user will not face the problem of losing any work. Additionally, if your application requests FileIOPermission and if it is a trusted application, the administrator can adjust security policy to allow it to execute from the remote share.
If your code does not access protected resources or perform protected operations, you do not need to request any permissions. For example, a permission request might not be necessary if the code simply computes a result based on inputs passed to it, without using any resources. If your code does access protected resources but does not request the necessary permissions, it might still be allowed to execute, but it could fail at some point during execution if it attempts to access a resource for which it does not have the necessary permission.
To request permissions, you must know which resources and protected operations your code uses, and you must also know which permissions protect those resources and operations. In addition, you need to keep track of any resources accessed by any class library methods that are called by your components. For a list of the code access permissions that are included with the .NET Framework, see the Permissions topic.
The following table describes the types of permission requests.
Permission request |
Description |
|---|---|
Minimum permissions (RequestMinimum) |
Permissions your code must have in order to run. |
Optional permissions (RequestOptional) |
Permissions your code can use but can run effectively without. This request implicitly refuses all other permissions not specifically requested. |
Refused permissions (RequestRefuse) |
Permissions that you want to ensure will never be granted to your code, even if security policy allows them to be granted. |
Perform any of the above requests on built-in permission sets (Requesting Built-in Permission Sets). |
Built-in permission sets, including Nothing, Execution, FullTrust, Internet, LocalIntranet, and SkipVerification. |
Perform any of the above requests on XML-encoded permission sets (Requesting XML-Encoded Permissions). |
XML representation (either a string containing the XML-encoded permission set or the location of an XML file containing the encoded permission set) of a desired permission set. |
If you specify required permissions (using RequestMinimum), the code will be granted each required permission that security policy allows. The code will be allowed to run only if it is granted all the permissions it requires.
Requesting optional permissions without also requesting required permissions can, in some cases, severely restrict the permissions granted to an assembly. For example, suppose security policy normally grants Assembly A the permissions associated with the Everything named permission set. If the developer of Assembly A requests Permission A as optional and does not request any required permissions, Assembly A will be granted either Permission A (if security policy allows it) or no permissions at all.
See Also
Tasks
How to: Request Permission for a Named Permission Set
Concepts
Requesting XML-Encoded Permissions
Reference
SecurityAction.RequestOptional