¿Por qué Mercurial devuelve "Cancelar: Acceso denegado" al intentar enviar un repositorio?

access-control

Question

Tengo un problema con un usuario que no puede empujar sus compromisos en un repositorio de Mercurial y estoy perplejo de por qué no está funcionando para él. He intentado varias cosas para descubrir qué es lo que pasa, buscar en Google no resulta útil ... así que aquí estoy.

Primero, la configuración. Tenemos una máquina con Windows XP SP2 x64 en nuestra red que actúa como nuestro servidor de repositorio oficial. Esto contiene varios repositorios en él. Clonamos / empujamos / tiramos usando una carpeta en esa unidad que está compartida. Los permisos se dan a todos para el acceso de lectura. Los usuarios que pueden presionar (incluido el usuario que tiene problemas), reciben el control total. La máquina del usuario está basada en Win XP. Mi máquina (utilizada para ayudar a solucionar problemas) también está basada en Win XP.

En segundo lugar, los síntomas. El usuario está utilizando TortoiseHg 2.1.1 para hacer su trabajo. Puede clonar bien, los compromisos con su repo local son aok, etc. Cuando intenta presionar, sin embargo, TortoiseHg devuelve un código de "abortar, ret 255". No muy útil. Por lo tanto, hemos ido a la línea de comandos y hemos emitido "hg push -v --debug". Aquí se devuelve "abortar: Acceso denegado". Este mismo usuario puede escribir en la carpeta compartida del servidor sin problemas, también puede crear archivos, directorios y eliminar los mismos. Por lo tanto, el acceso de lectura / escritura a la unidad / carpeta no es un problema.

En tercer lugar, nuestros resultados de experimentación. Aquí hay algunos resultados extraños de las pruebas. El usuario creó un nuevo repositorio de prueba local. Me conecté a la máquina del servidor y creé un repositorio de prueba para que él empujara. El usuario verificó un archivo y luego lo subió al repositorio de prueba en la máquina del servidor. Esto funcionó bien. No abortas. La vida era buena Él fue capaz de hacer algunos empujones más y siguió funcionando como se esperaba. Luego cloné el repositorio a mi máquina, actualicé un archivo y lo volví a colocar. Después de que el usuario introdujera mis cambios e intentara volver al servidor, una vez más encontró el temido mensaje "Acceso denegado". Mientras tanto, todavía puedo actualizar el proyecto sin ningún problema.

Como otro experimento, tuvimos que el usuario se desconectó y otro usuario inició sesión. Lo hicieron y pudieron enviar el servidor al repositorio sin ningún problema. El usuario original vuelve a iniciar sesión, realiza algunos cambios, etc. y una vez más golpea el muro de "Acceso denegado".

Por lo que podemos decir, el problema no está relacionado con las credenciales de Windows. De lo contrario, esperamos que la creación de archivos arbitrarios en la carpeta compartida del servidor no funcione. Además, hasta que hiciera una actualización del repo de prueba que creó el usuario, él podría presionar a ese repo en particular muy bien.

¿Algunas ideas? ¿Qué verificación adicional de credenciales está haciendo Mercurial que podría causar esto?

ACTUALIZAR:

Después de una sugerencia de Wim, comencé a ver los permisos en los diversos objetos del repositorio usando ''cacls''. Esta es una herramienta de Windows que "muestra o modifica las listas de control de acceso de los archivos". Hice que el usuario creara un nuevo repositorio y luego tomé una instantánea de los permisos. Luego registré un archivo en el mismo repositorio y tomé otra instantánea de los cambios.

Resulta que hay varios permisos de archivos de repo que se actualizan como resultado de esto: undo.bookmarks, undo.branch, undo.desc, undo.dirstate, branchheads, 00changelog.i, 00manifest.i, undo y el único Archivo del repositorio. Todos estos archivos tenían permisos similares a los siguientes:

C:/Projects/Mercurial/hgtest4/.hg/store/undo BUILTIN/Administrators:F 
                                         NT AUTHORITY/SYSTEM:F 
                                         DOMAINxxxx/USERIDxxxx:F 
                                         BUILTIN/Users:R 

(Se han modificado los valores reales de DOMAINxxxx y USERIDxxxx). Antes de mi registro, DOMAINxxxx y USERIDxxxx reflejaban el dominio y el ID de usuario del usuario. Después de mi registro, estos se actualizaron a los míos (estamos en el mismo dominio, pero el ID de usuario es obviamente diferente). Pude registrar el ingreso y la salida a pesar de que mi ID de usuario no estaba en la lista porque soy un miembro del grupo BUILTIN / Administrators. El usuario con el problema no es. Entonces, supongo que después de verificar las cosas, el sistema ya no lo veía como un usuario acreditado con acceso de escritura (BUILTIN / Usuario: R indica acceso de solo lectura) y, por lo tanto, causó la denegación del acceso.

Tengo una solución de preguntas y respuestas terribles en este momento (el usuario ahora es parte del grupo de administradores ...) La solución real será obtener el repositorio de Windows Sharing y acceder a la configuración de servidor adecuada.

Answer 1

Él fue capaz de hacer algunos empujones más y siguió funcionando como se esperaba. Luego cloné el repositorio a mi máquina, actualicé un archivo y lo volví a colocar. Después de que el usuario introdujera mis cambios e intentara volver al servidor, una vez más encontró el temido mensaje "Acceso denegado".

Parece que su inserción crea o modifica archivos en la carpeta .hg de tal manera que son (o se vuelven) inaccesibles para el otro usuario.

No soy un experto en permisos de archivos NTFS, pero creo que puede arreglar tales situaciones forzando a todo el contenido de la carpeta a heredar sus permisos. Intente seleccionar " Reemplazar todos los permisos de objetos secundarios con permisos heredables de este objeto " en la configuración de Seguridad avanzada de la carpeta.

Sin embargo, no se recomienda compartir los archivos del repositorio directamente con el uso compartido de archivos de Windows. Necesita un proceso de servidor entre los usuarios y los archivos del repositorio por motivos de rendimiento, integridad de los datos y seguridad. Sin un controlador de acceso de este tipo, otorgar acceso de compromiso también significa otorgar la capacidad de destruir / corromper los archivos del repositorio (o, como lo descubrió en este caso, cambiar sus permisos).

Consulte Publicación de repositorios mercuriales en la wiki de mercurial para obtener más información sobre otras opciones.

Answer 2

Acabo de tener el mismo problema abort: Access is denied . La causa fue que mi firewall (Privatefirewall) bloqueó silenciosamente algunas acciones de hg.

Answer 3

Al intentar confirmar en mi repositorio clonado localmente de un repositorio de código en mi recurso compartido de red, recibía el mismo mensaje de error:

00manifest.i Access is denied

Probablemente demasiado simplista, pero la eliminación de algunos de los permisos de solo lectura de los archivos ofensivos hizo que mi hg commit funcionara bien.

Answer 4

Recibía exactamente el mismo mensaje de error al intentar hg push en el indicador de comandos de Windows. Hace poco recibí un nuevo perfil de usuario después de que el anterior se hubiera dañado. Entonces me encontré con este error "Acceso denegado" . En TortoiseHg recibí un mensaje similar de "Anulado: Error 255" .

Intenté el consejo dado aquí por ya que parecía encajar; dadas mis nuevas credenciales de usuario. Finalmente, seguí el error a un Windows Git mal instalado. Solo estaba fallando cuando usaba repositorios con sub-repos de git.

En caso de que otros tengan un problema similar con los sub-repos de Git:

• Compruebe que Git está instalado correctamente. Lo quité y lo reinstalé completamente. (Consulte: https://code.google.com/p/msysgit/downloads/list para la última versión).
• Asegúrese de que la ruta a Git esté en la variable de entorno de ruta. ( Haga clic con el botón derecho en Mi PC -> pestaña Opciones avanzadas -> Variables de entorno ). No olvide que a algunas aplicaciones no les gustan las rutas de Windows con espacios, por lo que es posible que deba reemplazar "Archivos de programa" por "PROGRA ~ 1" (posiblemente "PROGRA ~ 2" en sistemas de 64 bits).
• Si está utilizando un proxy, asegúrese de que HTTP_PROXY y HTTPS_PROXY en las variables de entorno también estén configuradas correctamente.