在网上有些文章指出SPSecurity.RunWithElevatedPrivileges 这个方法实际上是用了IIS 中应用程序池中的用户去代替当前用户去运行,委托中的代码。这的确如此
但是这个方法并不是一步到位,直接的去使用应用程序池的用户,而是通过了一个所谓的“代理人”去完成这个事。无论在将Moss 的Web 应用程序部署为Windows 集成身份验证还是自定义的Forms 验证,在Moss 的所有列表库或文档库中的权限列表中,都会看到一个人,就是SHAREPOINT\System 这个用户,这个用户也是映射为当前的web 应用的网站集管理员,一般是第一个管理员。
Moss 2007 中,就是通过这个系统默认的管理帐号去模拟IIS 中应用程序池的用户,来达到对当前用户操作提升权限的效果。这就是说,其实在提升权限之后的一切操作都是以这个系统帐户(SHAREPOINT\system) 的身份去执行的,所以可以看到,若通过提升权限后进行的对文档库或列表进行添加、修改,在列表项的作者或修改人都会是系统帐户,而不是当前登录那个人的帐户,除非当前登录的人是网站集的管理员。
因为,SPSecurity.RunWithElevatedPrivileges 是通过模拟一个固定的帐户去进行操作,所以就带来了另一个问题,就是当这“代理人”系统帐户对列表或文档没有权限的时候,就像上图那样,系统帐户对列表的权限是受限访问,SPSecurity.RunWithElevatedPrivileges 就会不起作用,而且在代码的层面上很难发现这个问题。所以在需要通过调用SPSecurity.RunWithElevatedPrivileges来提升权限操作的列表或文档库,都需要确保系统帐户(SHAREPOINT\system)在该列表或文档库中存在,并且这个帐户的权限必须为完全控制。
这样调用提升权限时才会成功。
http://www.cnblogs.com/xivi/archive/2008/03/21/1116344.html