Requesting Permissions

Artykuł
02/04/2013

Important
In the .NET Framework version 4, runtime support has been removed for the RequestMinimum, RequestOptional, and RequestRefuse permission requests. This topic does not apply to code that is based on the .NET Framework 4 or later. For more information about this and other changes, see Security Changes in the .NET Framework 4.

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 than has been granted. The local administration policy always has final control over the maximum permissions your code is granted.

Note

Code that is intended to reside on a computer runs in the My_Computer_Zone, which, by default, has full trust. Full trust causes all permission requests to be approved. Demands for permissions always succeed, even for identity permissions where the identity condition is not met. If your code is intended to run only in the My_Computer_Zone, there is no value in requesting permissions. If your code is intended to run in any of the other zones, requesting permissions is recommended.

Note

In the .NET Framework 3.5 Service Pack 1 and later, applications in shares on the intranet run in full trust by default. If your application is intended to run from a share, it will run in full trust just like an application that is residing on a computer. For more information, see Running Intranet Applications in Full Trust.

Although your code does not have to request permissions in order to run in partial trust, 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. You can determine the permissions your application requires from the Security tab on the project properties page for a Visual Studio project. 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.

Udostępnij za pośrednictwem

Requesting Permissions

See Also

Tasks

Reference

Concepts

Other Resources

Dodatkowe zasoby