SharePoint 2007 - RunWithElevatedPrivileges - Pitfalls of using this

Question

I have a strong gut feeling that using SharePoint RunWithElevatedPrivileges should be avoided like the plague, but need to convince some others as to exactly why. Here's what I have.

• Spawns a new thread with elevated privileges
• Blocks other operations until the passed delegate returns
• Security problems (runs with a high level of privileges, perhaps by an end user)
• Others?

Answer 1

Reasons to elevate fall into two categories:

1. Your code needs to perform operations in SharePoint for which the current user does not have permissions. This should always be done while working with SharePoint security, not as a "just in case" measure which indicates you need to understand your security situation better.
2. Your code needs to access external resources (server file system, database, file share, etc) to which the application pool identity has access but the current user does not.

For the former, you're much better off using SPSite impersonation. The latter is the only reason I ever use RWEP.

To clarify, RWEP does not spawn a new thread. Instead it uses Win32 APIs to revert the current thread's identity back to the process identity (turning off impersonation) to run the elevated code, then switch impersonation back on to resume work on behalf of the current user. This has several implications:

1. RWEP does nothing if the thread isn't impersonated, so it is useless in timer jobs, Visual Studio workflows, console applications, and code run via stsadm (feature receivers).
2. Access to SharePoint, assuming you create a new SPSite in your CodeToRunElevated, will be performed with the rights of the application pool (SHAREPOINT\system). This account will have full access to the current web application, but should not have farm-level permissions to do things like modify SPFarm properties or make changes to the SSP.
3. Using identity-aware objects (like SPSite and its children) across the execution boundaries of your CodeToRunElevated has the potential to cause some really funky behavior and race conditions. For all intents and purposes, consider this unsupported.

And as Alex said, children of an SPSite inherit their permissions from the SPSite, which in turn has its permissions set when it is created. So SPContext.Current.Site will still behave with the permissions of the current user even if you reference it within your CodeToRunElevated. Instead, you would need to create and consume a new SPSite within the elevated block.

To summarize: RWEP to impersonate the App Pool outside of SharePoint, SPSite impersonation to impersonate the App Pool inside of SharePoint.