A few days ago I already published a blog post about the effects of running your PowerShell code in an elevated privileges block. In the past days I made some further tests to check what kind of effect the permission elevation might have if the code runs out of the SharePoint web application context, for example, in the case of server side console applications, windows services or PowerShell scripts, just to name a few typical cases.
To test the effects, I’ve created a simple console application in C#, and a PowerShell script.
I’ve tested the application / script with two different permissions. In both cases, the user running the application was neither site owner (a.k.a. primary administrator) nor a secondary administrator. In the first case, the user has the Full Control permission level on the root web of the site collection, in the second case the user has no permissions at all.
In C# I’ve defined a CheckIfCurrentUserIsSiteAdmin method as:
- private void CheckIfCurrentUserIsSiteAdmin(string url)
- {
- using (SPSite site = new SPSite(url))
- {
- using (SPWeb web = site.OpenWeb())
- {
- SPUser currentUser = web.CurrentUser;
- Console.WriteLine("Current user ({0}) is site admin on '{1}': {2}", currentUser.LoginName, url, currentUser.IsSiteAdmin);
- Console.WriteLine("Current user ({0}) is site auditor on '{1}': {2}", currentUser.LoginName, url, currentUser.IsSiteAuditor);
- Console.WriteLine("Effective permissions on web: '{0}'", web.EffectiveBasePermissions);
- try
- {
- Console.WriteLine("web.UserIsWebAdmin: '{0}'", web.UserIsWebAdmin);
- }
- catch (Exception ex)
- {
- Console.WriteLine("'web.UserIsWebAdmin' threw an exception: '{0}'", ex.Message);
- }
- try
- {
- Console.WriteLine("web.UserIsSiteAdmin: '{0}'", web.UserIsSiteAdmin);
- }
- catch (Exception ex)
- {
- Console.WriteLine("'web.UserIsSiteAdmin' threw an exception: '{0}'", ex.Message);
- }
- }
- }
- }
Then called it without and with elevated permissions:
- string url = http://YourServer;
- Console.WriteLine("Before elevation of privileges");
- CheckIfCurrentUserIsSiteAdmin(url);
- Console.WriteLine("After elevation of privileges");
- SPSecurity.RunWithElevatedPrivileges(
- () =>
- {
- CheckIfCurrentUserIsSiteAdmin(url);
- });
The summary of the result:
If the user executing the application has full permission on the (root) web (Full Control permission level):
Before elevation:
Current user is site admin: False
Effective perm.: FullMask
web.UserIsWebAdmin: True
web.UserIsSiteAdmin: False
After elevation:
Current user is site admin: True
Effective perm.: FullMask
web.UserIsWebAdmin: True
web.UserIsSiteAdmin: True
If the user has no permission on the (root) web:
Before elevation:
Current user is site admin: False
Effective perm.: EmptyMask
web.UserIsWebAdmin: ‘Access denied’ exception when reading the property
web.UserIsSiteAdmin: ‘Access denied’ exception when reading the property
After elevation:
Current user is site admin: True
Effective perm.: FullMask
web.UserIsWebAdmin: True
web.UserIsSiteAdmin: True
In PowerShell I defined a CheckIfCurrentUserIsSiteAdmin method as well, and invoked that without and with elevated right:
function CheckIfCurrentUserIsSiteAdmin($url) {
$site = Get-SPSite $url
$web = $site.RootWeb
$currentUser = $web.CurrentUser
Write-Host Current user $currentUser.LoginName is site admin on $url : $currentUser.IsSiteAdmin
Write-Host Current user $currentUser.LoginName is site auditor on $url : $currentUser.IsSiteAuditor
Write-Host Effective permissions on web: $web.EffectiveBasePermissions
Write-Host web.UserIsWebAdmin: $web.UserIsWebAdmin
Write-Host web.UserIsSiteAdmin: $web.UserIsSiteAdmin
}
$url = "http://YourServer"
Write-Host Before elevation of privileges
CheckIfCurrentUserIsSiteAdmin $url
Write-Host After elevation of privileges
[Microsoft.SharePoint.SPSecurity]::RunWithElevatedPrivileges(
{
CheckIfCurrentUserIsSiteAdmin $url
}
)
The results were the same as in the case of the C# console application, except the web.UserIsWebAdmin and web.UserIsSiteAdmin, when calling with no permissions on the web. In case we don’t receive any exception, simply no value (neither True nor False) was returned.
These results show, that any code, let it be a method in a standard SharePoint API, or a custom component, that depends on the above tested properties, behaves differently when using with elevated privileges, even if it is executed from an application external to the SharePoint web application context, that means, even if the identity of the process does not change.
