Permiso de identidad del grupo de aplicaciones IIS 7.5 no asignado a la carpeta, pero la aplicación aún puede escribir en su carpeta?

Question

Hemos puesto una aplicación existente en un nuevo servidor R2 con IIS 7.5.

Ahora todo funciona, y la aplicación puede escribir en sus carpetas ... pero nos preguntamos cómo ... el nuevo IIS viene con IIS Application Pool Identity que crea un nuevo usuario virtual para cada aplicación, y así lo ha hecho Para este.

Se indica en la documentación que este usuario debe asignarse a las carpetas para que todo funcione ... pero en nuestro caso, ¿no? Y aún funciona, ¿la aplicación a través de ese usuario tiene acceso?

En algún lugar de los foros, alguien mencionó que esto se debe a que las aplicaciones que se ejecutan bajo plena confianza pueden escribir cualquier cosa en cualquier lugar ... ¿pero eso no tiene sentido? ¿CAS en lo que sé no maneja esto?

Entonces, en IIS 7.5, ¿cómo puede una aplicación con su propio grupo tener permisos de escritura que no tiene la configuración de seguridad de la carpeta?

Vladan

Answer 1

EDITAR:

Mientras que siento lo que se describe a continuación es una buena discusión de cómo los niveles de confianza de jugar en el acceso al sistema de archivos en ASP.NET, siento la respuesta correcta a la original la pregunta se publica here (sí, tuve que volver a esta pregunta con un poco más de información agregada). Básicamente, el usuario AppPoolIdentity también es miembro del grupo Users, y así es como el usuario puede escribir en diferentes áreas del sistema de archivos.

RESPUESTA ORIGINAL:

Cuando se crea un nuevo grupo de aplicaciones en IIS 7.5, el usuario se agrega al grupo AppPoolIdentity IIS_IUSRS. Este grupo tiene "acceso a todos los recursos necesarios del sistema y del archivo para que una cuenta, cuando se agrega a este grupo, pueda actuar sin problemas como una identidad de grupo de aplicaciones" (1). El grupo IIS_IUSRS tiene permisos para escribir en la gran mayoría del sistema de archivos (fuera de las carpetas protegidas como C: \, C: \ Users, C: \ Windows, etc.). Desafortunadamente, no pude encontrar ninguna forma de ver explícitamente que el grupo IIS_IUSRS tiene acceso a una carpeta determinada usando Windows Explorer (edit: la publicación mencionada anteriormente describe cómo "ver" este acceso). Sin embargo, este acceso se puede ver implícitamente otorgando acceso DENY al grupo IIS_IUSRS en una carpeta antes de intentar escribir en esa carpeta (lo que provocará un System.UnauthorizedAccessException).

Los niveles de confianza de .NET también juegan en los permisos. En IIS 7.5, el usuario de IIS AppPoolIdentity tiene acceso para escribir en la carpeta donde se está ejecutando la aplicación de forma predeterminada si la aplicación web se está ejecutando en plena, alta o media confianza. Cuando se ejecuta con plena o alta confianza, el usuario IIS AppPoolIdentity puede escribir de forma predeterminada en cualquier carpeta que no sea carpetas como C: \, C: \ Windows o C: \ Users (a menos que se le otorgue acceso específico a esas carpetas). A nivel de confianza medio, el usuario IIS AppPoolIdentity todavía puede escribir en la carpeta de aplicaciones web por defecto, pero tratando de escribir a cualquier otro resultado de la carpeta en la siguiente excepción:

System.Security.SecurityException: Solicitud de permiso del tipo 'System.Security.Permissions.FileIOPermission, mscorlib, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089' falló.

La misma excepción se produce al intentar escribir en CUALQUIER archivo con niveles de confianza bajos o mínimos.

Este no es el mismo error que recibe al intentar acceder a un archivo que el usuario AppPoolIdentity no tiene acceso a cuando se ejecuta en completa o alta confianza. La excepción lanzada en ese caso es un System.UnauthorizedAccessException, con un mensaje similar a:

System.UnauthorizedAccessException: acceso a la ruta 'C: \ test.txt' es negado.

En niveles de confianza medios, bajos o mínimos CAS toma el control y niega el acceso a los métodos de creación de archivos, independientemente de los permisos de la carpeta.

La historia corta es que si quiere asegurarse de que su aplicación web no pueda escribir en ninguna carpeta que no sea la carpeta de la aplicación web, debe configurar la aplicación para que se ejecute en nivel de confianza medio o inferior. Si lo hace, debe realizar una prueba para asegurarse de que no haya funciones que la aplicación deba realizar y que requieran una confianza superior a Medium.

Referencias:

1 - http://learn.iis.net/page.aspx/140/understanding-built-in-user-and-group-accounts-in-iis-7/

2 - http://technet.microsoft.com/en-us/library/dd163542.aspx