SharePoint 2010 Sandbox Solutions

Sandbox is a safe virtual container, in which untrusted programs can run safely. In this environment, program runs in strict limitations on what system resources the program can access. Sandboxes are used when executable code comes from unknown or untrusted sources and allow the user to run untrusted code safely.
A sandboxed solution can be monitored by two levels of administrators, the site collection administrator monitor the site collection and farm administrator monitors on per site collection basis through central admin site. A sandboxed solution can be deployed easily by site administrator of a site collection.
Architecture:
The sandbox in SharePoint is implemented as a separate process where your sandbox solution code will run. In fact, there are three processes.
User Code Service
SPUCHostService.exe, also known as the User Code Service. This service runs on each server on the farm that we are going to allow to work in the sandbox. Thus the infrastructure ogres can choose to run this service on all, or only a certain subset of the servers in the farm. This is an important consideration, because this constitutes an important part around the administration of sandbox solution infrastructure, namely the load balancing aspects. There are two approaches to load balancing sandbox solutions on your SharePoint Farm.
Sandbox Worker Process
The sandbox worker process SPUCWorkerprocess.exe is where your actual code runs! This is in contrast to having the code run inside of w3wp.exe. This is why you don't have to restart the application pool every time your redeploy an sandbox solution.
Sandbox Worker Process Proxy
The Sandbox worker process proxy SPUCWorkerProcessProxy.exe, which is built on the new services infrastructure in SharePoint.
Sandbox assemblies run under a separate service called as SPUserCodeV4. The sandboxed solutions are also restricted by an out of the box CAS policy. The CAS policy for sandbox solutions grants you the following policy permissions:
1. SharePointPermission.ObjectModel
2. SecurityPermission.Execution
3. AspNetHostingPermission.Level = Minimal
With default CAS, there is a limited access to SharePoint Object Model, No file I/O, no call to web service. There are two other important points to note in this out of the box CAS Policy
1. While your code is restricted to the CAS policy permissions defined above, it allows the SharePoint framework code full trust.
2. If your custom code needs to break out of this sandbox's boundaries, you can always write a full-trust proxy.

This means we can’t elevate privileges in such an environment and we land up with complex solutions, sandbox solutions are bad in such scenarios. However, before implementing any sandbox solutions, we must consider constraints under which it has to be executed.
With Sandbox solutions, web parts derived from Microsoft.SharePoint.WebPartPages.WebPart is not supported, only support web parts derived from System.Web.UI.WebControls.WebPart namespace.

Disadvantages of Sandbox solutions:
1. No support to Microsoft.SharePoint.WebPartPages namespace.
2. It’s more secure, can’t elevate privileges and leads to more complex codes.
3. Making web service calls over the internet, or accessing code that is not marked to allow partially trusted callers are not supported. You also can’t deploy files to disk or add assemblies to the GAC in a sandboxed solution, and security-related functionality, such as running RunWithElevatedPriviledges and other SPSecurity methods, is not allowed.
4. No support to SPUtility.SendEmail namespace for sending mails.