SharePoint 2007 - RunWithElevatedPrivileges - Trampas de usar este

Question

Tengo un fuerte presentimiento de que el uso de SharePoint RunWithElevatedPrivileges se debe evitar como la peste, pero necesito convencer a algunos otros como exactamente por qué. Aquí es lo que tengo.

• genera un nuevo hilo con privilegios elevados
• Bloques otras operaciones hasta que pasaron los retornos de delegado
problemas
• Seguridad (carreras con un alto nivel de privilegios, tal vez por un usuario final)
• Otros?

Answer 1

Las 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 se debe hacer mientras se trabaja por de seguridad de SharePoint, no como una medida "por si acaso", que indica que hay que entender su situación de seguridad mejor.
2. El código necesita acceder a recursos externos (sistema de servidor de archivos, bases de datos, compartir archivos, etc.) a la que la identidad del grupo de aplicaciones tiene acceso el usuario actual, pero no lo hace.

En el primer caso, es mucho mejor usar SPSite suplantación . Esta última es la única razón por la que nunca utilizo RWEP.

Para aclarar, RWEP no generar un nuevo subproceso. En su lugar utiliza las API de Win32 para revertir la identidad del subproceso actual de nuevo a la identidad de proceso (apagar suplantación) para ejecutar el código elevada, luego cambiar suplantación de nuevo 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, y ejecutar código a través de Stsadm (receptores de características).
2. El acceso a SharePoint, suponiendo que se crea un nuevo SPSite en su CodeToRunElevated, se llevará a cabo con los derechos del grupo de aplicaciones (SHAREPOINT \ system). Esta cuenta tendrá acceso completo a la aplicación web actual, pero no debe tiene permisos a nivel de granja para hacer cosas como modificar las propiedades SPFarm o realizar cambios en la SSP.
3. El uso de objetos de identidad-consciente (como SPSite y sus hijos) a través de los límites de su ejecución CodeToRunElevated tiene el potencial de causar algunas condiciones de comportamiento y de raza realmente chulas. Para todos los efectos, considere esto no compatible.

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

Para resumir:. RWEP para suplantar al grupo de aplicaciones fuera de SharePoint, suplantación SPSite para suplantar al grupo de aplicaciones dentro de SharePoint

Answer 2

1) el uso sustancial de RWEP es una buena indicación del código de olores. Se puede abusar fácilmente sin pensamiento que conduce a graves problemas de seguridad. Muchos desarrolladores no piensan en lo que los usuarios podrían hacer con el poder que indirectamente se está dando "bajo el capó".

Sólo un ejemplo: es importante llamar ValidateFormDigest antes de usar RWEP a prevenir solicitudes maliciosos en páginas de aplicación .

---

objetos

2) SPWeb y SPSite necesitan ser creados en el contexto de RWEP. Esto es fácil para los desarrolladores novatos para olvidar, lo que lleva a una gran frustración.

Esta restricción también significa que todo el trabajo y todos los objetos creados por estos objetos tienen que ser utilizados y terminó con antes de que finalice el delegado RWEP. Este es otro error común.

Keith Dahlby ha escrito métodos de extensión para moverse por estos problemas, dando código más robusto y de fácil lectura.

Answer 3

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

Si usted está preocupado por el usuario final ejecuta RWEP, probablemente ya tiene un problema mayor, ya que el código ya se ha instalado en la GAC.

A veces, sólo tiene que seguir con ella: supongamos que un usuario que no tiene derechos de administrador, ejecutar un flujo de trabajo de documentos. Después de este usuario aprueba (o rechazar, no importa), su motor de flujo de trabajo debe ser capaz de redefinir los privilegios que SPListItem.

Answer 4

Yo lo uso, y parece que es una funcionalidad muy útil. En mi opinión, estoy eligiendo para permitir al usuario ejecutar el código y tienen ese código de hacer cosas que el usuario normalmente no podría hacer. Puede bloquear algo abajo, y todavía dejar que el acceso de los usuarios de una manera muy controlada.