SPSecurity.RunWithElevatedPrivileges()

The subject of today's post: running code in sharepoint with elevated rights, an operation sometimes required, sometimes abused and often misunderstood.

The WSS Object Model provides a huge number of classes, some of which can carry-out potentially dodgy actions, so require elevation to run. Ordinarily you'd just deal with this by logging in as a user with rights to carry out the operation, but occasionally this isn't practical or possible, and that's where today's subject comes in.

Let's say, just as an example, you're creating an anonymously-accessible site. In a Control on on of the pages you want to enumerate subsites of your site, and grab some properties thereof, maybe for display, maybe for some other operation in your code - however, this isn't something an anonymous identity can do.

In steps our hero - RunWithElevatedPrivileges()

Used correctly, this method allows a specified block of code to run in the context of the SharePoint System Account, a powerful method with much potential. Here's the summary from the SDK:

[SharePointPermissionAttribute(SecurityAction.Demand, Impersonate=true)]
[SharePointPermissionAttribute(SecurityAction.Demand, ObjectModel=true)]
public static void RunWithElevatedPrivileges (
    CodeToRunElevated secureCode
)

 Now the CodeToRunElevated parameter can be a reference to a void, parameterless method or an anonymous method via delegate() - please, follow the SDK link if that's unclear.

Pretty simple, huh? Yep, well as always there's a catch or two.

1. If you're manipulating any Object Model elements within your elevated method, you need to get a fresh SPSite reference inside this call. For example

SPSecurity.RunWithElevatedPrivileges(delegate(){   SPSite mySite = new SPSite(https://sharepoint/);   SPWeb myWeb = SPSite.OpenWeb();   // further implementation omitted});

2. You can't just use SPContext.Current.Site to get your SPSite reference - or you'll ber handed the object with the security context of the anonymous (or non-elevated) user and your elevation will not work as expected.

3. If you need to Update() anything inside this block, you'll need to call SPSite.AllowUnsafeUpdates() on your new site reference (or web reference) as per this SDK entry.

So those are the gotchas. Following those we have the obvious security warnings - be careful what you do within this call, as the system identity has full control over SharePoint and could do Very Bad Things if incorrectly used. Sanitise any user input very carefully if you're going to let it anywhere near this method - you certainly don't want a user finding some injectable exploit into this code. Exercise caution over what you do, for this power must be used wisely. But you knew that, right?

Comments

• Anonymous
  January 01, 2003
  Hi, I have written a web service and used the SPSecurity.RunWithElevatedPrivileges to access a list to do some operations. But when I access that web service through the application, it asks for user name and password. Ideally it should not ask for user name and password. Please tell me - what should I have to do so that user name and password will not be asked for accessing the web service?

• Anonymous
  May 30, 2012
  This is very useful. Thanks very much.

• Anonymous
  November 29, 2012
  Best article to know all ways of using RuWithElevatedPrivileges. sharepointquicksolutions.blogspot.in/.../all-ways-of-runwithelevatedprivileges.html

• Anonymous
  July 25, 2013
  This article saved us! Thank you very much! Can't get to run with elevated privelages till i saw this site! Thanks!