SharePoint 2007 - RunWithElevatedPrivileges - Errores de usar este

Question

Tengo una fuerte intuición de que el uso de SharePoint RunWithElevatedPrivileges debe evitarse como la peste, pero es necesario convencer a otros para saber exactamente por qué. Esto es lo que tengo.

• genera un nuevo hilo con privilegios elevados
• Bloques otras operaciones hasta que el delegado pasado vuelve
• Los problemas de seguridad (se ejecuta con un alto nivel de privilegios, tal vez por un usuario final)
• Otros?

Answer 1

Razones para elevar dividen en dos categorías:

1. el código necesita para llevar a cabo operaciones en SharePoint para el cual el usuario actual no tiene permisos. Esto siempre debe hacerse al trabajar con seguridad de SharePoint, no como una medida "por si acaso", lo que indica que necesita comprender mejor su situación de seguridad.
2. Su código necesita acceder a los recursos externos (sistema de archivos del servidor, base de datos, recurso compartido de archivos, etc.) a los que tiene acceso la identidad del grupo de aplicaciones, pero el usuario actual no.

Para el primero, es mucho mejor usar SPSite impersonation. Esta última es la única razón por la que uso RWEP.

Para aclarar, RWEP no genera un nuevo hilo. En su lugar, utiliza las API de Win32 para revertir la identidad del hilo actual a la identidad del proceso (desactivar la suplantación) para ejecutar el código elevado y luego volver a activar la suplantación para reanudar el trabajo en nombre del usuario actual. Esto tiene varias implicaciones:

1. RWEP no hace nada si el hilo no se suplanta, por lo que es inútil en los trabajos del temporizador, flujos de trabajo de Visual Studio, las aplicaciones de consola, ejecutar el código a través de stsadm (receptores de función).
2. El acceso a SharePoint, suponiendo que cree una nueva SPSite en su CodeToRunElevated, se realizará con los derechos del grupo de aplicaciones (SHAREPOINT \ system). Esta cuenta tendrá acceso completo a la aplicación web actual, pero no debe tener permisos de nivel de granja para hacer cosas como modificar propiedades de SPFarm o realizar cambios en el SSP.
3. El uso de objetos sensibles a la identidad (como SPSite y sus hijos) a través de los límites de ejecución de su CodeToRunElevated tiene el potencial de causar un comportamiento realmente funky y condiciones de carrera. Para todos los efectos, considere esto sin respaldo.

Y como dijo Alex, los hijos de un SPSite heredan sus permisos del SPSite, que a su vez tiene sus permisos establecidos cuando se crea. Así que SPContext.Current.Site todavía se comportará con los permisos del usuario actual, incluso si lo hace referencia dentro de su CodeToRunElevated. En cambio, necesitaría crear y consumir un nuevo SPSite dentro del bloque elevado.

Para resumir: RWEP para suplantar el Pool de aplicaciones fuera de SharePoint, la suplantación SPSite para suplantar el Pool de aplicaciones dentro de SharePoint.

Answer 2

RWEP, como todo lo demás, tiene sus pros y sus contras.

Si le preocupa que el usuario final ejecute RWEP, probablemente ya tenga un problema mayor, ya que ese código ya se ha instalado en GAC.

A veces, solo tiene que seguir con esto: considere un usuario que no tiene derechos de administrador, ejecutando un flujo de trabajo de documentos. Después de que este usuario aprueba (o rechaza, no importa), su motor de flujo de trabajo debería poder redefinir los privilegios de SPListItem.

Answer 3

Lo uso, y encuentro que es una funcionalidad muy útil. En mi opinión, estoy eligiendo dejar que el usuario ejecute mi código y hacer que ese código haga cosas que el usuario normalmente no podría hacer. Puede bloquear algo y aún así permitir que el usuario acceda a él de forma muy controlada.

Answer 4

1) El uso sustancial de RWEP es una buena indicación de los olores del código. Se puede abusar fácilmente sin pensarlo, lo que genera serios problemas de seguridad. Muchos desarrolladores no piensan en lo que los usuarios podrían hacer con el poder que indirectamente se les da "debajo del capó".

Solo un ejemplo: es importante llamar a ValidateFormDigest antes de usar RWEP al prevent malicious requests in application pages.

---

2) SPWeb y SPSite objetos necesitan ser creados en el contexto de RWEP. Esto es fácil de olvidar para los desarrolladores noveles, lo que genera mucha frustración.

Esta restricción también significa que todo el trabajo y cualquier objeto creado por estos objetos deben ser utilizados y terminados antes del final del delegado RWEP. Este es otro error común.

Keith Dahlby ha escrito extension methods para evitar estos problemas, dando un código más robusto y legible.