|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
Using Libraries from Partially Trusted Code
Applications that receive less than full trust by the runtime code access security system are not allowed to call shared managed libraries unless the library writer specifically allows them to through the use of the AllowPartiallyTrustedCallersAttribute Class. Therefore, application writers must be aware that some libraries will not be available to them from a partially trusted context. By default, all code that executes from the local intranet or Internet zones is partially trusted. If you do not expect your code to be executed from a partially trusted context or to be called by partially trusted code, you do not need to be concerned about the information in this section. However, if you write code that must interact with partially trusted code or operate from a partially trusted context, you should consider the following factors:
Libraries must be signed with a strong name in order to be shared by multiple applications. Strong names allow your code to be placed in the global assembly cache and allow consumers to verify that a particular piece of mobile code actually originates from you.
By default, strong-named shared libraries perform an implicit LinkDemand for full trust automatically, without the library writer having to do anything.
If a caller does not have full trust but still tries to call such a library, the runtime throws a SecurityException and the caller is not allowed to link to the library.
In order to disable the automatic LinkDemand and prevent the exception from being thrown, you can place the AllowPartiallyTrustedCallersAttribute attribute on the assembly scope of a shared library. This attribute allows your libraries to be called from partially trusted managed code.
Partially trusted code that is granted access to a library with this attribute is still subject to further restrictions defined by local machine policy.
There is no programmatic way for partially trusted code to call a library that does not have the AllowPartiallyTrustedCallersAttribute attribute. If an application does not receive full trust by default, an administrator must choose to modify security policy and grant the application full trust before it can call such a library.
Libraries that are private to a specific application do not require a strong name or the AllowPartiallyTrustedCallersAttribute attribute and cannot be referenced by potentially malicious code outside the application. Such code is protected against intentional or unintentional misuse by partially trusted mobile code without the developer or administrator having to do anything extra.
You should consider explicitly enabling use by partially trusted code for the following types of code:
Code that has been diligently tested for security vulnerabilities and is in compliance with the guidelines described in Secure Coding Guidelines.
Strong-named code libraries that are specifically written for partially trusted scenarios.
Any components (whether partially or fully trusted) signed with a strong name that will be called by mobile code downloaded from the Internet or the local intranet. These components are affected because under default security policy mobile code receives partial trust.
If default policy is modified, any code that security policy grants less than full trust.
Some classes shipped in the .NET Framework class library do not have the AllowPartiallyTrustedCallersAttribute attribute and cannot be called by partially trusted code. See .NET Framework Assemblies Marked with AllowPartiallyTrustedCallersAttribute for a list of classes that are callable by partially trusted code.