Restrictions on Sandboxed Solutions in SharePoint 2010

Article
10/20/2016

This topic describes the restrictions on code that runs in sandboxed solutions in Microsoft SharePoint 2010.

Applies to: SharePoint Foundation 2010

The various restrictions can be usefully sorted into the following categories, based on the mechanisms that impose the restrictions.

Warning

The Sandbox Solution framework provides a mechanism for executing user-provided code outside of the IIS worker process. The Sandbox Solution framework should not be used as a mechanism for enforcing security boundaries when executing user code. Sandbox Solutions are not supported as a security boundary with user code, especially code of unknown origin. We advise against executing Sandbox Solutions of unknown origins.

Triple Worker Processes

As explained in Sandboxed Solutions Architecture in SharePoint 2010, sandboxed code runs in a separate worker process from the standard Microsoft ASP.NET worker process, and it makes calls to a third, full-trust proxy process. This fact imposes some restrictions on sandboxed solutions regardless of the permissions of the sandboxed worker process.

Restriction	Implications and Remarks
The WebResources.axd handler, which runs in the ASP.NET worker process, cannot access resources embedded in assemblies in the sandboxed worker process.	Assemblies in sandboxed solutions cannot use embedded resources.

Low-Privileged Security Token for the Sandboxed Worker Process

The sandboxed worker process is given a low-privileged security token. (This is not the same as the user security token.) The token imposes the following restrictions.

Restriction	Implications and Remarks
Code in the process cannot read or write to the file system (except that it can read and execute assemblies in the global assembly cache).	Application pages, mobile pages, and user controls (.ascx files) cannot be deployed in a sandboxed solution. Neither can Visual Web Parts because they include a user control. Delegate controls that are implemented as user controls are also not possible in a sandboxed solution. However, certain other kinds of files can be deployed to the content database and, thus, can be included in sandboxed solutions. These include script files, image files, and assemblies. (For more information, see How to: Create and Deploy a non-RESX Resources in a Sandboxed Solution and Where are Assemblies in Sandboxed Solutions Deployed?) Note The Microsoft Visual StudioExtensions gallery has an extension that enables you to add a Visual Web Part to a sandboxed solution project. This enables the use of the visual designer, but the user control (ASCX file) is compiled along with the code behind into the assembly. It is not deployed with the solution. Hence, the advantages of ASCX deployment are not enabled by this extension. Site definitions require a WebTemp.xml file, hence they cannot be deployed in a sandboxed solution. However, you can deploy custom site types in sandboxed solutions by using a WebTemplate element instead of a WebTemp.xml file. For more information, see How to: Deploy a Web Template in a Sandboxed Solution. Resource (.resx) files cannot be deployed in a sandboxed solution, but there are ways to localize sandboxed solutions without deploying resource files to the server file system. For more information, see Localization of Sandboxed Solutions in SharePoint 2010. Web.config files cannot be deployed with a sandboxed solution, nor can they be modified. The same point applies to supplemental .config files. For more information, see How to: Create a Supplemental .config File. In combination with the unavailability of the SPWebConfigModification class (see later in this topic), this means that you cannot modify web.config settings in a sandboxed solution.
Code in the process cannot call to the network.	Only resources that are available on the server that is running the sandboxed worker process can be accessed. An external database, for example, cannot be accessed. This means that a BCS Model cannot be deployed in a sandboxed solution.
Code in the process cannot write to the registry.
Code in the process cannot call any assembly that is not deployed to the global assembly cache. (An exception to this rule is assemblies that are deployed as part of the sandboxed solution. For more information, see Where are Assemblies in Sandboxed Solutions Deployed?)	Microsoft SharePoint Foundation and SharePoint Server assemblies that are not installed in the global assembly cache cannot be called by code that runs in the sandboxed worker process. For example, the Microsoft.SharePoint.UserCode.dll assembly cannot be called.

Important

The security token of the sandboxed worker process does not apply to calls made to APIs in the Microsoft.SharePoint.dll because those APIs run in a separate, fully trusted process. For example, the fact that the security token for the sandboxed worker process blocks access to external databases does not prevent a sandboxed solution from accessing an external list on a SharePoint website. Neither does it block access to a standard SharePoint list when the content database is on a different server from the server that handles the sandboxed solution. For more information, see Sandboxed Solutions Architecture in SharePoint 2010.

Restrictive Code Access Security Policy for the Sandboxed Worker Process

The code access security (CAS) policy for the sandboxed solution worker process is defined in the file %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG\wss_usercode.config, and it is referenced in the web.config file located at %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode. This policy grants only the permissions in the following table.

Permission Granted	Remarks
SharePointPermission.ObjectModel	However, not every class in the object model is available from sandboxed code. See the section Special Versions of the Microsoft.SharePoint.dll Assembly later in this topic.
SecurityPermission.Execution
AspNetHostingPermission = Minimal	The minimal permission level allows execution of resources, but not read/write access to resources or any other permissions for the resources. Calls to unmanaged code are not allowed.

The following table is a selection of permissions that are not granted by the CAS policy.

Permission Denied	Remarks
DirectoryServicesPermission
DnsPermission
EnvironmentPermission
EventLogPermission
FileIOPermission	Absence of this permission denies sandboxed code read/write access to the file system. The same right is also denied by the security token of the sandboxed worker process.
IsolatedStorageFilePermission
PrintingPermission
ReflectionPermission	Absence of this permission denies sandboxed code access to the ASP.NET Reflection APIs and, thus, to non-public classes and members in managed code.
RegistryPermission	Absence of this permission denies sandboxed code access to the registry. The same right is also denied by the security token of the sandboxed worker process.
SecurityPermission	Absence of this permission denies sandboxed code access to unmanaged code and to the threading and application domain subsystems. Absence of this permission also makes it more difficult for rogue code to evade the restrictions of the CAS policy.
SmtpPermission
SqlClientPermission	Absence of this permission means that code in the sandboxed solution cannot access the SharePoint databases. An exception to this rule is that code that calls the Microsoft.SharePoint.dll can access the databases, assuming the call is allowed by the special versions of that assembly. For more information about these special assemblies and the role they play, see Special Versions of the Microsoft.SharePoint.dll Assembly later in this topic. Important Often calls to APIs in SharePoint Foundation and SharePoint Server assemblies other than Microsoft.SharePoint.dll will fail because of this restriction even when the assembly is in the global assembly cache and has the AllowPartiallyTrustedCallers attribute. Only Microsoft.SharePoint.dll has the special versions that allow calls to it to escape the sandboxed worker process and run in a full-trust process.
SocketPermission
UIPermission
WebPermission

For more information about CAS policies, see the following:

Important

The CAS policy of the sandboxed worker process does not apply to calls made to APIs in the Microsoft.SharePoint.dll because those APIs run in a separate, fully trusted process. For example, a call to GetLocalizedString can read from resource files in the file system. For more information, see Sandboxed Solutions Architecture in SharePoint 2010.

Note

The CAS policy makes an exception for strong-named Microsoft Office assemblies. These are granted full trust.

Assemblies Without the AllowPartiallyTrustedCallers Attribute Cannot Be Called

A CAS policy that gives less than full trust to code in the sandboxed worker process has an important side effect, regardless of the details of the policy: Code governed by the CAS policy can call only assemblies with the AllowPartiallyTrustedCallersAttribute. So code in the sandboxed worker process cannot call any assemblies, including Microsoft .NET Framework, SharePoint Foundation, and SharePoint Server assemblies that lack this attribute. The following table notes some implications of this restriction.

Assembly without AllowPartiallyTrustedCallers Attribute	Implications and Remarks
Microsoft.SharePoint.WorkflowActions	Coded workflows cannot be deployed in a sandboxed solution because such workflows require access to classes in this assembly. ("No code" workflows, created in Microsoft SharePoint Designer and possibly modified in Visual Studio, can be deployed in sandboxed solutions.)

For lists of which .NET Framework and SharePoint assemblies are, and are not, available, see Available and Unavailable .NET Assemblies from Sandboxed Solutions in SharePoint 2010 and Available and Unavailable SharePoint Assemblies from Sandboxed Solutions in SharePoint 2010.

Special Versions of the Microsoft.SharePoint.dll Assembly

As explained in Sandboxed Solutions Architecture in SharePoint 2010, calls from code in the sandboxed worker process to the Microsoft.SharePoint.dll are redirected to a special version of that assembly. The special version is in some ways less privileged than other assemblies in the sandboxed worker process, but in other ways it is more privileged.

The most significant restriction is that the special version contains only a subset of the standard assembly's classes and methods. An exception is thrown when code calls an API that is not included in the special version of the assembly. The following table notes a few of the APIs that are not included in the special version of the assembly. For a complete list of classes that are included, see Microsoft.SharePoint.dll APIs That Are Available from Sandboxed Solutions.

Blocked API	Implications and Remarks
Most of the Microsoft.SharePoint.Administration namespace, including the SPWebApplication and SPFarm classes.	Features in a sandboxed solution cannot be deployed to either Farm or WebApplication scope. Hence, the kind of Features that can be deployed only to these scopes cannot be deployed at all in a sandboxed solution. For example, a Business Data Connectivity Model cannot be deployed in a sandboxed solution. Almost no objects and resources above the site collection level in the object model are available to sandboxed solutions. Document converters, which are registered with the web application, cannot be registered in a sandboxed solution.
All of the control classes in the Microsoft.SharePoint.WebControls namespace.	Code in sandboxed solutions is restricted to ASP.NET controls.
The WebPartMobileAdapter class.	Sandboxed code cannot contain a Web Part mobile adapter.
The Microsoft.SharePoint.WebPartPages.WebPart class.	Sandboxed solutions can include only Web Parts derived from the ASP.NET class System.Web.UI.WebControls.WebParts.WebPart.
SPJobDefinition	Timer jobs cannot be included in sandboxed solutions.
SPWebConfigModification	You cannot programmatically modify web.config settings with a sandboxed solution. In combination with the fact that sandboxed solutions cannot read or write to the server file system (see earlier in this topic), this means that you cannot modify web.config settings in a sandboxed solution.
RunWithElevatedPrivileges	Methods in a sandboxed solution cannot be configured to run with the elevated privileges of the user identity in which the application pool runs.

In addition, even when a method is included in the special version of the assembly, it may impose additional restrictions on the parameters passed to the API. For example, the SPSite(String) and SPSite(Guid) constructors are available to sandboxed solutions, but only URLs or GUIDs that refer to the site collection in which the sandboxed solution is installed can be passed to them. This prevents a sandboxed solution from accessing any websites, lists, or other resources from outside the site collection to which it has been installed.

Finally, the special version of the assembly makes some read/write properties read-only in the sandbox. For more information, see Methods and Properties That Are Available with Restrictions.

But calls to Microsoft.SharePoint.dll that are allowed by the special assembly gatekeeper are more privileged in one very important way, when compared to calls to any other assembly: The API that is called does not run in the restricted sandboxed worker process. Instead the call is forwarded to a full-trust proxy process where the API executes without restriction. This means that such calls can do things, such as access the SharePoint databases, that cannot be done by calls to any other assemblies, not even other SharePoint assemblies.

Split Page Rendering System

As explained in Sandboxed Solutions Architecture in SharePoint 2010, when a client computer requests a SharePoint page that includes a component from a sandboxed solution, such as a Web Part deployed in a sandboxed solution, SharePoint renders more than one page object. One is rendered in the ASP.NET worker process (w3wp.exe), and the others are rendered in the sandboxed worker process. All non-sandboxed components are rendered on the page in the ASP.NET worker process, while the first sandboxed component is rendered on a page object in the sandboxed worker process. When the page in the sandboxed worker process is fully rendered, it is merged into the page object in the ASP.NET process. If the there is more than one sandboxed component on the page that the user requested, each of them is rendered separately on their own page object in the sandboxed worker process. Each such page object, in turn, is merged into the page object in the ASP.NET process.

One implication of this system is that a Web Part that is deployed in a sandboxed solution can be neither a provider nor a consumer Web Part in a Web Part connection. This is because each sandboxed Web Part renders entirely in a separate page object of its own. (Cross-page Web Part connections are possible with Web Parts that derive from the Microsoft.SharePoint.WebPartPages.WebPart class, but that class is blocked by the shim Microsoft.SharePoint.dll—see earlier in this topic. Only Web Parts derived from the System.Web.UI.WebControls.WebParts.WebPart class are supported in sandboxed solutions, and they do not allow cross-page Web Part connections.)

There is another implication of the split page rendering system. Some ASP.NET types cannot be merged from a page object in the sandboxed process into the final page that is returned. This means that it would be pointless for code in a sandboxed solution to write to properties of the ASP.NET Page object (or its child objects) that hold objects of these unmergable types. The following table identifies some of these types.

Unmergable Type	Implications and Remarks
ClientScriptManager	Sandboxed code should not write to the ClientScript property. However, client-side script can be registered with the page in other ways. For example, you could embed the script as a LiteralControl and add it to a control collection in a CreateChildControls() method.
ScriptManager	Sandboxed code should not add a ScriptManager object to the controls collection of any object.
Cache	Sandboxed code should not write to the Cache property.
MasterPage	Sandboxed code should not write to the Master property. However, it can point the page to a different master page by writing to the MasterPageFile property.
HttpSessionState	Sandboxed code should not write to the Session property.

Resource Usage Limitations

Sandboxed solutions cannot overuse system resources. This requirement is enforced by the SharePoint Foundation resource monitoring infrastructure.

For more information, see Resource Usage Limits on Sandboxed Solutions in SharePoint 2010 and Sandboxed Solutions Architecture in SharePoint 2010.

Farm-Relative Validation of Solutions

Farm administrators may impose custom solution validation on sandboxed solutions. These may effectively impose additional restrictions on what can be done by a sandboxed solution. You must find out from farm administrators what validators they are using.

Farm-Relative Blocking of Solutions

Farm administrators can put any sandboxed solution on a list of blocked solutions in Central Administration.

Farm-Relative Blocking of Classes

Farm administrators can run custom code that blocks specified managed classes from being called in the sandboxed worker process. For more information, see SPRestrictedObjectModel.

Miscellaneous Limitations

The following table identifies restrictions on sandboxed solutions that do not fit neatly into the other sections of this topic.

Restriction	Remarks and Implications
You cannot deploy a HideCustomAction element in a sandboxed solution.	You cannot use a sandboxed solution to hide a menu item, ribbon button, or link on an administration page, such as the Site Settings page. However, you can add a new custom action to any of these with a sandboxed solution. For more information, see What Can Be Implemented in Sandboxed Solutions in SharePoint 2010.
You cannot deploy a CustomActionGroup element in a sandboxed solution.	Although you can add new custom action in a sandboxed solution, you cannot create a new action group for your custom actions. For more information, see What Can Be Implemented in Sandboxed Solutions in SharePoint 2010.
You cannot register a control candidate for a delegate control (Control element) in a sandboxed solution.