Mixing RunWithElevatedPrivileges and SharePoint List Permissions


Checking user permissions against SharePoint artefacts is straightfordward enough, many types within the object model expose a range of overloaded DoesUserHavePermissions(…) methods, the example below checks that the current user has ViewListItems permissions against a list.

private bool DoesUserHavePermission(SPList list)
{
	var hasPerms = listToCheck.DoesUserHavePermissions(SPBasePermissions.ViewListItems);
	return hasPerms;
}

This example assumes that you’ve already got a reference to the list to check, SharePoint security trimming means that you may not be able to get  a reference to the list in question in order to check permission against it;

using (var site = new SPSite(_site.ID))
using (var web = site.OpenWeb(_web.ID))
{
	list = web.Lists["Some List"];
}

In this example, if I don’t have sufficient permissions against the list I’m looking for it won’t appear in the Lists collection, and an exception would be thrown.

This is all fine and well, but there are many circumstances in which it’s desirable to be able to check for permissions against artefacts, for which you may not have the permission to get a reference to the artefact in the first place.

One solution is to get the artefact reference using elevated security, SPSecurity.RunWithElevatedPrivileges, then use the artefact reference with elevated security to check for the permissions required.

SPSecurity.RunWithElevatedPrivileges(delegate
{
	using (var site = new SPSite(_site.ID))
	using (var web = site.OpenWeb(_web.ID))
	{
		list = web.Lists.Cast<SPList>()
						.FirstOrDefault(l => l.Title.Equals("Some List"));
	}
});

With this method there is something to watch out for, in the next example, the current user does not have ViewListItems permission to the list, however the method will return true, indicating incorrectly that they do.

private bool DoesUserHavePermission(SPList list)
{
	var hasPerms = listToCheck.DoesUserHavePermissions(SPBasePermissions.ViewListItems);
	return hasPerms;
}

The failure only looks like a failure, it is in fact working correctly – and this is because, the SPList reference was created under the elevated security context. To correctly check the current users permission against such an elevated artefact reference, you must use the overloaded method which accepts a security priciple, as shown in the next example.

private bool DoesUserHavePermission(SPList list)
{
	var hasPerms = listToCheck.DoesUserHavePermissions(SPContext.Current.Web.CurrentUser,
                                       SPBasePermissions.ViewListItems);
	return hasPerms;
}

Published by

Phil Harding

SharePoint Consultant, Developer, Father, Husband and Climber.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s