SharePoint 2007 - RunWithElevatedPrivileges - Ловушки использования этого

Question

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

• Нерест нового потока с повышенными привилегиями
• блоков других операций, пока передаваемый делегат не возвращает
• проблем безопасности (бежит с высоким уровнем привилегий, может быть конечным пользователем)
• других?

Answer 1

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

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

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

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

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

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

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

Answer 2

RWEP, как и все остальное, имеет за и против.

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

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

Answer 3

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

Answer 4

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

Только один пример: очень важно вызвать ValidateFormDigest перед использованием RWEP до prevent malicious requests in application pages.

---

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

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

Keith Dahlby написал extension methods, чтобы обойти эти проблемы, предоставляя более надежный и удобочитаемый код.