3 out of 4 rated this helpful - Rate this topic

SPSecurity.RunWithElevatedPrivileges Method

Executes the specified method with Full Control rights even if the user does not otherwise have Full Control.

Namespace:  Microsoft.SharePoint
Assembly:  Microsoft.SharePoint (in Microsoft.SharePoint.dll)
Available in Sandboxed Solutions: No
public static void RunWithElevatedPrivileges(
	SPSecurity..::..CodeToRunElevated secureCode
)

Parameters

secureCode
Type: Microsoft.SharePoint.SPSecurity.CodeToRunElevated
A delegate method that is to run with elevated rights. This method runs under the Application Pool identity, which has site collection administrator privileges on all site collections hosted by that application pool.

The secureCode object can be created from any method that is parameterless and returns void. See SPSecurity.CodeToRunElevated.

You can also bypass using the SPSecurity.CodeToRunElevated constructor by defining an anonymous method inside the call to RunWithElevatedPrivileges.

Important note Important

If secureCode includes any write operations, then the call to RunWithElevatedPrivileges should be preceded by a call of either SPUtility.ValidateFormDigest() or SPWeb.ValidateFormDigest().

The first example shows RunWithElevatedPrivileges used with the SPSecurity.CodeToRunElevated constructor. In this example, GetSitesAndGroups is a parameterless method that returns void and is defined somewhere that can be accessed by the Button1_Click method.

protected void Button1_Click(object sender, EventArgs e)
{
   SPSecurity.CodeToRunElevated elevatedGetSitesAndGroups = new SPSecurity.CodeToRunElevated(GetSitesAndGroups);
   SPSecurity.RunWithElevatedPrivileges(elevatedGetSitesAndGroups);
}

The next example shows the syntax that is required to define an anonymous method in the call to RunWithElevatedPrivileges.

SPSecurity.RunWithElevatedPrivileges(delegate()
{
    // implementation details omitted
});

An SPSite object created outside the delegate can be referenced inside the delegate, however, the methods and property assessors of the object run with the privileges of the user context in which the objects were created, not with the elevated privileges. The same point applies to SPWeb objects and any other objects. You must create new objects inside the delegate if you need to execute the members of the objects with elevated privileges. If the new object must represent the same persisted entity as an object created outside the delegate, then you must reference identification information from the externally created object and use it to create the new object within the delegate. For example, if web is a reference to an SPWeb object created before the call to RunWithElevatedPrivileges, then the following code shows you would use the ID of its parent SPSite object to construct a new SPSite object.

SPSecurity.RunWithElevatedPrivileges(delegate()
{
    using (SPSite site = new SPSite(web.Site.ID))
    {
    // implementation details omitted
    }
});

Inside the delegate, members of the site object run with elevated privileges, but calls to members of web.Site would not. Note that the using keyword is used to ensure that the object is disposed in the delegate.

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
One last point
The other thing to remeber regarding this method call is that the account NAME that is being used is "SHAREPOINT/SYSTEM" and this does not resolve to an actual domain account.  Now the only time this becomes and issue is when one is refeing to Windows resources outside of SharePoint.  Again this is only intended to be used for resources within SharePoint.  If you function code is say calling even a SharePoint web service and one sets the web service "Credential" to "System.Network.CredentialCache.DefaultNetworkCredetial" that the service call will in fact fail because IIS will not be able to resolve the domain account "SHAREPOINT/SYSTEM".  If the case is one needs to access external data then consider using a Secure Store credential.
One last point
The other thing to remeber regarding this method call is that the account NAME that is being used is "SHAREPOINT/SYSTEM" and this does not resolve to an actual domain account.  Now the only time this becomes and issue is when one is refeing to Windows resources outside of SharePoint.  Again this is only intended to be used for resources within SharePoint.  If you function code is say calling even a SharePoint web service and one sets the web service "Credential" to "System.Network.CredentialCache.DefaultNetworkCredetial" that the service call will in fact fail because IIS will not be able to resolve the domain account "SHAREPOINT/SYSTEM".  If the case is one needs to access external data then consider using a Secure Store credential.
How it actually works
I've always found that the nuances of RunWithElevatedPrivileges cause much confusion as well as some weird and wonderful behavior if not properly understood. While the documentation here does a good job of explaining how and when to use it, it's missing a key piece of information and that's how the mechanism actually works.

Behind the scenes, RunWithElevatedPrivileges impersonates the identity of the current thread. In effect, this means that the delegate will run under the context of the application pool account, in the case of the code being called in the W3P process, or in the context of the SPTimerv4 service, in the case of the code being called in a workflow, timer job or anything else that's kicked off using the timer. If the code is running in a console application or some other user-initiated app, the delegate will be kicked off using the context of the user who started the application. (Which would be the default behavior anyway).

When using workflows, bear in mind that the workflow may start running under W3P but continue executing under owstimer (SPTimerV4) depending on what it's actually doing. In this case a delegate executed using RunWithElevatedPrivileges would not neccesarily yeild the same result.