Requesting Permissions

When you design and develop your assemblies, create a list of all the resources that your code accesses , and all the privileged operations that your code performs . At deployment time, the administrator may need this information to appropriately configure code access security policy and to diagnose security related problems.

The best way to communicate the permission requirements of your code is to use assembly level declarative security attributes to specify minimum permission requirements. These are normally placed in Assemblyinfo.cs or Assemblyinfo.vb. This allows the administrator or the consumer of your assembly to check which permissions it requires by using the Permview.exe tool.

RequestMinimum

You can use SecurityAction.RequestMinimum method along with declarative permission attributes to specify the minimum set of permissions your assembly needs to run. For example, if your assembly needs to access the registry, but only needs to retrieve configuration data from a specific key, use an attribute similar to the following:

 [assembly: RegistryPermissionAttribute(                      SecurityAction.RequestMinimum,                       Read=@"HKEY_LOCAL_MACHINE\SOFTWARE\YourApp")] 

If you know up front that your code will run in a full trust environment and will be granted the full set of unrestricted permissions, using RequestMinimum is less important. However, it is good practice to specify your assembly's permission requirements.

Note  

Permission attributes accept a comma-delimited list of properties and property values after the mandatory constructor arguments. These are used to initialize the underlying permission object. A quick way to find out what property names are supported is to use Ildasm.exe on the assembly that contains the permission attribute type.

RequestOptional

If you use SecurityAction.RequestOptional method, no other permissions except those specified with SecurityAction.RequestMinimum and SecurityAction.RequestOptional will be granted to your assembly, even if your assembly would otherwise have been granted additional permissions by code access security policy.

RequestRefused

SecurityAction.RequestRefuse allows you to make sure that your assembly cannot be granted permissions by code access security policy that it does not require. For example, if your assembly does not call unmanaged code, you could use the following attribute to ensure code access security policy does not grant your assembly the unmanaged code permission.

 [assembly: SecurityPermissionAttribute(SecurityAction.RequestRefuse,                                         UnmanagedCode=true)] 

Implications of Using RequestOptional or RequestRefuse

If you use RequestOptional , the set of permissions that are specified with RequestOptional and RequestMinimum are intersected with the permission grant given to your assembly by policy. This means that all other permissions outside of the RequestOptional and RequestMinimum sets are removed from your assembly's permission grant. Additionally, if you use RequestRefuse , the refused permissions are also removed from your assembly's permission grant.

So if you use RequestOptional or RequestRefuse , your assembly becomes a partial trust assembly, which has implications when you call other assemblies. Use the following considerations to help you decide whether you should use SecurityAction.RequestOptional or SecurityAction.RequestRefuse :

• Do not use them if you need to directly call a strong named assembly without AllowPartiallyTrustedCallersAttribute (APTCA) because this prevents you from being able to call it.

  Many strong named .NET Framework assemblies contain types that do not support partial trust callers and do not include APTCA. For more information, and a list of assemblies that support partial trust callers , see "Developing Partial Trust Web Applications," in Chapter 9, "Using Code Access Security with ASP.NET."

  If you must call strong named assemblies without APTCA, let the administrators who install your code know that your code must be granted full trust by code access security policy to work properly.

• If you do not need to access any APTCA assemblies, then add permission requests to refuse those permissions that you know your assembly does not need. Test your code early to make sure you really do not require those permissions.

• If downstream code needs the permission you have refused, a method between you and the downstream code needs to assert the permission. Otherwise, a SecurityException will be generated when the stack walk reaches your code.