AnkhSVN rompe los permissions de uso compartido de ASP.NET con SVN 1.7

El background (salte a la parte inferior si quiere la pregunta)

Recientemente actualicé un repository SVN (alojado en assembla) a SVN 1.7. Después de hacerlo, comenzamos a encontrar intermitentemente muchos errores de File Access Denied en las páginas del sitio ASP.NET que se encuentran en la copy de trabajo local del repository.

Algunas carpetas también comenzaron a get permissions de files extraños (se marcaron como de solo lectura) y se les quitó el uso compartido de los usuarios. Estos problemas solo comenzarían a ocurrir después de un ciclo de actualización / confirmación, a través del complemento Visual Studio de AnkhSVN, pero no todo el time; parecía altamente temperamental.

La única solución temporal que hemos encontrado hasta el momento es realizar cambios pendientes, eliminar la copy local y volver a realizar una copy de trabajo completa (con TortoiseSVN). Sin embargo, esa no es una solución viable, y está afectando seriamente la productividad.

Este sitio es un WebWorkerRole de ASP.NET basado en Azure. Nunca ha dado problemas antes de la actualización a SVN 1.7. Intenté juguetear con los permissions internos de IIS para evitar el problema, sin embargo, no hay dados.

Mi entorno

  • Visual Studio 2010 Ultimate 10.0.40219.1 SP1
  • AnkhSVN 2.3.10509 (última versión, compatible con SVN 1.7.1)
  • TortoiseSVN 1.7.1, compilation 22161 – 64 bits
  • Ejecutar en modo de debugging a través del entorno del emulador de Azure

La pregunta

¿Es posible que SVN 1.7 o cualquiera de las herramientas de mi entorno rompa los permissions de files para que los files no se puedan utilizar en un sitio ASP.NET? y más importante, ¿cómo puedo arreglar esto?


El error exacto de permiso de file descartado es este:

El acceso a la ruta '// file //' está denegado.

Descripción: se produjo una exception no controlada durante la ejecución de la request web actual. Revise el seguimiento de la stack para get más información sobre el error y dónde se originó en el código.

Detalles de la exception: System.UnauthorizedAccessException: acceso denegado a la ruta '// file //'.

ASP.NET no está autorizado para acceder al recurso solicitado. Considere otorgar derechos de acceso al recurso a la identidad de la request ASP.NET. ASP.NET tiene una identidad de process base (típicamente {MACHINE} \ ASPNET en IIS 5 o Servicio de networking en IIS 6 e IIS 7, y la identidad configurada del grupo de aplicaciones en IIS 7.5) que se utiliza si la aplicación no se hace pasar por otra. Si la aplicación se está haciendo pasar por ella, la identidad será el usuario anónimo (generalmente IUSR_MACHINENAME) o el usuario de la request autenticada.

Para otorgar acceso a ASP.NET a un file, haga clic derecho en el file en el Explorador, select "Propiedades" y select la pestaña Seguridad. Haga clic en "Agregar" para agregar el usuario o grupo apropiado. Resalte la count ASP.NET y marque las casillas para el acceso deseado.

Pero una copy de trabajo limpia no generará este error. Al comparar los permissions de los dos, parece que las copys de trabajo que no tienen errores se comparten (con IUSR y la count local), mientras que las que se rompieron no se comparten, pero el usuario nunca cambia el uso compartido.

Lo resolví accediendo a la configuration de security de la carpeta del website y haciendo clic en Avanzado y luego en Cambiar permissions para el usuario de IIS_IUSRS. Revisé "Reemplazar todos los permissions de objects secundarios con permissions henetworkingables de este object" y hice clic en Aplicar.

Antes de eso, le había dado al usuario de IIS permissions completos para la carpeta oculta tmp en la raíz del process de finalización de la compra, pero no sé si esto ayuda con algo.

No estoy seguro de si esto es una solución permanente, pero en caso de que no lo sea, al less puede usarlo para volver a aplicar los permissions para todos los files en una sola operación.

Cuando subversion actualiza un file, primero crea una versión temporal en .svn / tmp /. A continuación, mueve el file a la location correcta. (Esto para evitar corrupciones)

En 1.6 hizo esto para cada directory por sí mismo, pero en 1.7 solo hay un .svn en el directory de nivel superior de su copy de trabajo.

Si de alguna manera los permissions del sistema de files de este directory .svn están restringidos, es posible que las restricciones se copien con el file cuando se mueva en su lugar. (Subversion no cambia los permissions en sí mismo en Windows)

Mucha información se encuentra en carpetas .svn dentro del directory donde se ejecutó el proyecto. Entonces, en mi opinión, es mejor usar SVN por separado de las herramientas de integración avanzadas. También esto trata de resolver un problema como este.

Encontré este mismo problema exactamente cuando hice un 'Revertir' usando:

  • Tortoise Svn 1.6.16
  • AnkhSVN 2.3.11269.1348.
  • Profesional de Visual Studio 2010
  • Windows 7 – 64 bit.

Estaba completamente perplejo la primera vez que encontré el error de permissions y comencé pensando que era mi código. Después de un time de juguetear, terminé borrando todo el proyecto y volviendo a download desde Subversion, que solucionó el problema.

Cuando volvió a ocurrir este problema, miré más de cerca el file revertido, y encontré que los permissions en los files revertidos no coinciden con los permissions de los otros files. Específicamente, los permissions de 'Usuarios' para la máquina en la que se está ejecutando Visual Studio faltan por completo.

Así que acabo de agregarlo por:

  • Haga clic derecho en el file del problema. Esto hizo que apareciera la window de properties del file.
  • Luego hizo clic en 'Editar …'. La window de permiso aparece.
  • Luego, hizo clic en Agregar y aparece la window 'Seleccionar usuarios, computadoras, counts de service o grupos'.
  • Haga clic en el button Tipos de objects y marque todas las casillas.
  • Haga clic en el button Ubicaciones y asegúrese de que el nombre de su máquina esté seleccionado.
  • Escriba 'usuarios' y luego click el button 'verificar nombres'.
  • Haga clic en Aceptar en todas las windows para cerrarlas.

Su website ahora debería ejecutarse sin el error de permissions.