SharePoint 2007 - RunWithElevatedPrivileges - 使用此漏洞的陷阱

Question

我有一种强烈的直觉,即RunWithElevatedPrivileges应该像瘟疫一样避免使用SharePoint ,但需要让其他人相信其确切原因.这就是我所拥有的.

• 生成具有提升权限的新线程
• 阻止其他操作,直到传递的委托返回
• 安全问题(可能由最终用户以高级别权限运行)
• 其他？

Answer 1

将跌倒分为两类的原因:

1. 您的代码需要在SharePoint中执行当前用户没有权限的操作.这应该始终在使用 SharePoint安全性时完成,而不是"以防万一",这表明您需要更好地了解您的安全状况.
2. 您的代码需要访问应用程序池标识可以访问但当前用户不能访问的外部资源(服务器文件系统,数据库,文件共享等).

对于前者,使用SPSite模拟会更好.后者是我使用RWEP的唯一原因.

为了澄清,RWEP不会产生新的线程.相反,它使用Win32 API将当前线程的标识恢复为进程标识(关闭模拟)以运行提升的代码,然后重新开启模拟以代表当前用户恢复工作.这有几个含义:

1. 如果线程未被模拟,则RWEP不执行任何操作,因此在计时器作业,Visual Studio工作流,控制台应用程序以及通过stsadm(功能接收器)运行的代码中无用.
2. 假设您在CodeToRunElevated中创建新的SPSite,将使用应用程序池(SHAREPOINT\system)的权限执行对SharePoint的访问.此帐户将具有对当前Web应用程序的完全访问权限,但不应具有服务器场级权限,以执行修改SPFarm属性或对SSP进行更改等操作.
3. 在CodeToRunElevated的执行边界中使用身份感知对象(如SPSite及其子代)可能会导致一些非常时髦的行为和竞争条件.出于所有意图和目的,请考虑这一点不受支持.

正如Alex所说,SPSite的子级继承了SPSite的权限,SPSite在创建时会权限设置.因此,即使您在CodeToRunElevated中引用它,SPContext.Current.Site仍将使用当前用户的权限.相反,您需要在提升的块中创建和使用新的SPSite.

总结一下:RWEP模拟SharePoint之外的App Pool,SPSite模拟模拟SharePoint内部的App Pool.