SharePoint 2010 Change context for RunWithElevatedPrivileges

Question

I have 2 Site Collections, lets just call them A and B. In A I have a list of some content that I want to syncdicate across multiple site collections. I have created a custom content query web part that queries the data but I am running into a road block.

Because the user level accounts don't have access to Site A at all, and I don't want them to have access to this site at any level, I get an access denied error when my web part runs on site B. Is there a way to change the context through which RunWithElevatedPrivileges works?

My current code which runs from site collection B looks like

ClientContext clientContext = new ClientContext(siteAUrl);
SP.List oList = clientContext.Web.Lists.GetByTitle(listName);

CamlQuery query = new CamlQuery();
//Add View, Execute Query, etc.

return results;

If I wrap this in SPSecurity.RunWithElevatedPrivileges it runs with elevated within the site collection B context where I would rather it run within the Site collection A context.

Answer 1

The SharePoint 2010 client object model does not support SPSecurity.RunWithElevatedPrivileges. As @Nat states this call reverts the thread identity to the application pool account (SystemAccount). Since you're code runs on the client, the identity can not be reverted to the application pool account. Running code as system account via the client object model would open a security hole. Everybody could write and execute code as an administrator.

If your code runs on the server, you can use the SPUserToken.SystemAccount to open a SPSite with the system account credentials:

using (SPSite site = new SPSite("http://someurl", SPUserToken.SystemAccount))
{
  // admin action here
}

Check out my blog post How to Open a SPSite with System Account Credentials for more information.

Answer 2

Remember that SPSecurity.RunWithElevatedPrivileges is running the code in the sercurity context of the application-pool account. Thus unless you are running site collections in different webapplications, they will have the same context. i.e. master of all that is surveyed.

If you are running across site collections, the application pool account will dictate the permissions on the other web application.