El error «detected dubious ownership in repository» de Git y la solución con safe.directory

Qué es

Git emite por sí mismo fatal: detected dubious ownership in repository at '<path>', seguido de To add an exception for this directory, call: y una línea de git config ya preparada, cuando un comando de Git accede a un repositorio cuyo worktree o directorio .git no pertenece al usuario que ejecuta Git. Git 2.35.2 introdujo esta comprobación como corrección de CVE-2022-24765: antes, un repositorio colocado por otro usuario en una ubicación compartida o con permisos de escritura para todos (un directorio temporal, un volumen montado) podía incluir una configuración que ejecutaba código elegido por el atacante en cuanto el proceso de Git de otra persona entraba en él. La misma comprobación se incluyó en 2.30.3, 2.31.2, 2.32.1, 2.33.2 y 2.34.2. El texto "dubious ownership" apareció con la corrección posterior de CVE-2022-29187 (2.37.1, 2.36.2, 2.35.4 y los backports equivalentes); las versiones corregidas anteriores muestran en su lugar fatal: unsafe repository ('<path>' is owned by someone else). La propia referencia de configuración de Git documenta el ajuste safe.directory, que controla la lista de permitidos resultante; Git solo lo lee de la configuración del sistema, la global o la de la línea de comandos, nunca de la configuración del propio repositorio.

Por qué importa

La comprobación se activa constantemente en entornos corrientes que, aun así, cruzan una frontera de UID: un repositorio clonado en una etapa de construcción de un contenedor y montado con lectura y escritura en otra que se ejecuta con un usuario distinto; un runner de CI que hace el checkout con una cuenta y ejecuta los pasos con otra; un directorio del host montado por bind mount en un contenedor cuyo usuario no coincide con el propietario de los archivos del host. Nada de esto es un ataque, pero Git no puede distinguirlo desde dentro de la comprobación, así que se niega a operar en todos los casos por igual.

Cómo aplicarlo

• Diagnóstico: compara ls -ld <repo> (propietario) con id -u/id -un de la cuenta que ejecuta realmente Git; git config --global --get-all safe.directory muestra lo que ya está en la lista de permitidos.
• Soluciones, de la menos a la más invasiva:
  1. Confiar solo en este repositorio: git config --global --add safe.directory /path/to/repo.
  2. En un trabajo de CI efímero donde la ruta del checkout es impredecible pero todo el entorno es desechable y de propósito único, git config --global --add safe.directory '*' es la forma documentada de desactivar por completo la comprobación (Git 2.35.3, 2.30.4 y posteriores); limítalo únicamente a esa cuenta desechable.
  3. Mejor que cualquiera de las dos: eliminar la discrepancia de UID en sí. Ejecutar chown -R "$(id -u):$(id -g)" /path/to/repo (requiere root o derechos de propiedad) antes de usar Git, o alinear el usuario del contenedor con el propietario del volumen, corrige la causa real en lugar de suprimir la comprobación cada vez que vuelva a saltar.
• Inseguro: configurar safe.directory '*' en un entorno de larga duración, multiusuario o interactivo. Eso reabre justo la brecha que cerró CVE-2022-24765, para todos los repositorios que la cuenta llegue a tocar, incluido uno que un atacante coloque más adelante.

Trampas

• La configuración con --system aplica la lista de permitidos a todos los usuarios del host, no solo a quien la estableció.
• Bajo sudo, Git 2.37.0, 2.36.2, 2.35.4 y posteriores también confían en los repositorios cuyo propietario es el usuario indicado en SUDO_UID, pero puede que lean un $HOME/.gitconfig distinto del de la shell interactiva, de modo que una entrada safe.directory añadida para una cuenta no se aplica a la otra.