SharePoint 2007 - RunWithElevatedPrivileges - Подводные камни использования этого

Question

У меня сильное предчувствие, что использования SharePoint RunWithElevatedPrivileges следует избегать, как чумы, но мне нужно убедить некоторых других точно, почему. Вот что у меня есть.

• Создает новый поток с повышенными привилегиями
• Блокирует другие операции, пока переданный делегат не вернет
• Проблемы безопасности (работает с высоким уровнем привилегий, возможно, от конечного пользователя)
• Другие

Answer 1

Причины повышения делятся на две категории:

1. Ваш код должен выполнять операции в SharePoint, для которых у текущего пользователя нет разрешений. Это всегда следует делать при работе с безопасностью SharePoint, а не в качестве меры «на всякий случай», которая указывает на то, что вам необходимо лучше понять ситуацию с вашей безопасностью.
2. Вашему коду необходим доступ к внешним ресурсам (файловая система сервера, база данных, общая папка и т. Д.), К которым у удостоверения пула приложений есть доступ, а у текущего пользователя нет.

Для первых вам гораздо лучше использовать SPSite олицетворение . Последнее - единственная причина, по которой я когда-либо использовал RWEP.

Чтобы уточнить, RWEP не создает новую ветку. Вместо этого он использует API-интерфейсы Win32, чтобы вернуть идентификатор текущего потока обратно к идентификатору процесса (отключив олицетворение), чтобы запустить повышенный код, а затем снова включить олицетворение, чтобы возобновить работу от имени текущего пользователя. Это имеет несколько последствий:

1. RWEP ничего не делает, если поток не олицетворен, поэтому он бесполезен в заданиях таймера, рабочих процессах Visual Studio, консольных приложениях и коде, выполняемом через stsadm (приемники функций).
2. Доступ к SharePoint, если вы создадите новый SPSite в вашем CodeToRunElevated, будет осуществляться с правами пула приложений (SHAREPOINT \ system). Эта учетная запись будет иметь полный доступ к текущему веб-приложению, но не должен иметь права на уровне фермы для таких вещей, как изменение свойств SPFarm или внесение изменений в SSP.
3. Использование объектов, учитывающих идентичность (таких как SPSite и его дочерние элементы) через границы выполнения вашего CodeToRunElevated, может привести к некоторым действительно странным поведениям и условиям гонки. Для всех намерений и целей, сочтите это неподдерживаемым.

И, как сказал Алекс, дочерние элементы сайта SPS наследуют свои разрешения от сайта SPS, который, в свою очередь, имеет свои права доступа, установленные при его создании. Поэтому SPContext.Current.Site будет по-прежнему работать с разрешениями текущего пользователя, даже если вы ссылаетесь на него в вашем CodeToRunElevated. Вместо этого вам нужно будет создать и использовать новый SPSite в блоке с повышенными правами.

Подводя итог: RWEP для олицетворения пула приложений вне SharePoint, SPSite олицетворение для олицетворения пула приложений внутри SharePoint.

Answer 2

1) Широкое использование RWEP является хорошим признаком запахов кода. Его можно легко обдумать, не задумываясь, что приводит к серьезным проблемам с безопасностью. Многие разработчики не задумываются о том, что пользователи могут сделать с той мощью, которую им косвенно дают «под капотом».

Только один пример: важно вызвать ValidateFormDigest перед использованием RWEP, чтобы предотвратить вредоносные запросы на страницах приложения .

<Ч />

2) Объекты SPWeb и SPSite необходимо создавать в контексте RWEP. Это легко забыть начинающим разработчикам, что приведет к большому разочарованию.

Это ограничение также означает, что вся работа и любые объекты, созданные этими объектами, должны использоваться и завершаться до окончания делегата RWEP. Это еще одна распространенная ошибка.

Кит Далби написал методы расширения , чтобы обойти эти проблемы, предоставляя более надежный и читаемый код.

Answer 3

RWEP, как и все остальное, имеет свои плюсы и минусы.

Если вы обеспокоены тем, что конечный пользователь запускает RWEP, возможно, у вас уже есть более серьезная проблема, поскольку этот код уже установлен в GAC.

Иногда вам просто нужно придерживаться этого: рассмотреть пользователя, у которого нет прав администратора, запустить рабочий процесс документа. После того, как этот пользователь одобрит (или отклонит, не имеет значения), ваш механизм рабочего процесса сможет переопределить эти привилегии SPListItem.

Answer 4

Я использую его и считаю его очень полезным функционалом. На мой взгляд, я предпочитаю позволить пользователю запускать мой код и заставлять этот код делать вещи, которые пользователь обычно не может делать. Вы можете заблокировать что-то, и все же позволить пользователю получить к нему доступ очень контролируемым образом.