The SHAREPOINT\system account is an identity to which WSS maps internally when code is running under the identity of the hosting application pool. The SHAREPOINT\system account is not recognized by Windows because it exists only within the content of the WSS runtime environment. This enables WSS to use a statically named account for system-related activity regardless of whatever Windows user account has been configured for the hosting application pool.
For example, if you switch the application pool from BWL\SP_WorkerProcess1 to BWL\SP_WorkerProcess2, code running as system code still acts and is audited as the SHAREPOINT\system account. However, it is also important to realize that SHAREPOINT\system is not recognized by the Windows security subsystem. Therefore, code in WSS running as system code is recognized under the identity of the hosting application pool when it attempts to access external resources, such as the local file system or a SQL Server database.
The SPSecurity class provides a static method named RunWithElevatedPrivileges that enables code to execute as system code running under the identity of SHAREPOINT\system. This allows code to run in an escalated security context to perform actions as the system. This method should be used with care and should not expose direct access to system resources, but rather should be used when you need to perform actions on behalf of the system. The method is simple. You can either create a delegate to a public void method or simply write code within an inline delegate. The signature looks like the following:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// Code runs as the “SharePoint\system” user
});
Code within the delegate runs under the Windows SHAREPOINT\system security principal. As covered in the previous section titled “Application Pool Identities,” this account uses the application pool identity when passing credentials to external resources, but it uses the system account internally. However, if you use code similar to the following, you would notice a bug in your code that seems to indicate that the security context has not been switched.
// Bad code example:
SPSecurity.RunWithElevatedPrivileges(
delegate() {
SPListItem record = visitorList.Items.Add();
// still the calling user:
record["User"] = SPContext.Current.Web.CurrentUser;
// uses authorization of the calling user, NOT the system:
record.Update();
}
);
To modify WSS content under the System credentials, you need to create a new SPSite site collection that generates a new security context for objects referenced from the site, as in the following example. You cannot switch the security context of the SPSite once it has been created, but must instead create a new SPSite reference to switch user contexts. The following code uses the system credentials to add a list item using the profile data of the current Web user:
SPSecurity.RunWithElevatedPrivileges(
delegate() {
using (SPSite site = new SPSite(web.Site.ID)) {
using (SPWeb web2 = site.OpenWeb()) {
SPList theList = web2.Lists["visitors"];
SPListItem record = theList.Items.Add();
record["User"] = SPContext.Current.Web.CurrentUser;
record.Update();
}
}
);
Code running with the escalated privilege should use a new SPSite object for code running as the system and use the SPContext.Current property to access the actual calling user’s identity.