Tecnología · GUÍA PRÁCTICA
Git “detected dubious ownership”: comprueba el límite de propietario antes de usar safe.directory
Trata el error fatal como un desacuerdo de identidad, no como un aviso molesto. Comprueba el usuario que ejecuta Git, el propietario del repositorio, el montaje y el ámbito de configuración antes de autorizar una sola ruta.
Git no lee la configuración de un repositorio cuyo árbol pertenece a otra identidad, salvo que la ruta esté autorizada explícitamente. La reparación segura consiste en demostrar qué usuario ejecuta Git y quién posee la ruta canónica, corregir una propiedad accidental y añadir una única excepción solo cuando el uso compartido es intencional.
1. Registrar la identidad y la ruta canónica
Reproduce el fallo en la misma shell, servicio, contenedor o paso de CI. Anota el usuario efectivo, la ruta exacta del mensaje y la ruta canónica del árbol. En Unix compara id -u e id -g con el propietario del repositorio y de cada directorio padre; en Windows inspecciona el SID desde el mismo cliente Git. No supongas que una terminal, una GUI, sudo, un servicio y un contenedor comparten identidad o archivo de configuración.
2. Clasificar el desacuerdo antes de cambiar nada
Si una restauración, un clone como administrador, un traslado de disco o una compilación como root dejaron un propietario accidental, corrígelo o ejecuta Git con la cuenta prevista. Si la diferencia es intencional por uso compartido, conserva el propietario y crea una excepción exacta. Si el sistema de archivos informa metadatos inestables, repite las mediciones y prueba una ruta bajo el punto de montaje o monta el directorio padre.
3. Ver qué configuración lee el proceso que falla
--global escribe la configuración del usuario que ejecuta el comando. Otra cuenta de servicio, usuario de contenedor o proceso de CI puede leer otro HOME. Ejecuta git config --show-origin --get-all safe.directory en el contexto que falla para ver valores y archivos. Usa el ámbito system solo si un administrador pretende una política para toda la máquina. El repositorio no puede declararse seguro desde su configuración local.
4. Aplicar la reparación mínima
Si el propietario es accidental, cambia solo el árbol del repositorio a la cuenta prevista y verifica; no amplíes permisos de padres ajenos. Si se comparte deliberadamente, añade una sola ruta canónica en la configuración protegida de la identidad que ejecuta Git. Evita *: Git lo define como exclusión total que trata todos los repositorios como seguros. Una ruta acabada en /* también confía en todo lo que hay debajo y solo corresponde a una raíz compartida controlada.
5. Repetir la operación real y revisar anidados
Repite git status y el comando original como el usuario original. Comprueba por separado submódulos, worktrees y repositorios anidados porque pueden cruzar otro límite. Un éxito accidental como root o con otro HOME no vale; vuelve a confirmar identidad y show-origin. Elimina entradas antiguas o comodines cuando funcione la ruta mínima y documenta por qué se confía en la propiedad compartida.
Por qué hay que respetar el aviso
La regla de propiedad siguió a CVE-2022-24765. GitHub explicó que un atacante en una máquina multiusuario podía colocar un .git en un directorio padre para que Git leyera configuración capaz de ejecutar comandos. La pregunta correcta no es “¿cómo lo silencio?”, sino “¿quién posee esta ruta, por qué es legítimo y cuánto puedo reducir la excepción?”.
