L'erreur Git « detected dubious ownership in repository » et le correctif safe.directory

Ce que c'est

fatal: detected dubious ownership in repository at '<path>' est un message émis par Git lui-même, suivi de To add an exception for this directory, call: et d'une ligne git config prête à l'emploi, lorsqu'une commande Git accède à un dépôt dont le worktree ou le répertoire .git n'appartient pas à l'utilisateur qui exécute Git. Git 2.35.2 a introduit cette vérification comme correctif de CVE-2022-24765 : auparavant, un dépôt placé par un autre utilisateur dans un emplacement partagé ou accessible en écriture à tous (un répertoire temporaire, un volume monté) pouvait contenir une configuration qui exécutait du code choisi par l'attaquant dès que le processus Git d'un autre utilisateur y entrait. La même vérification a été livrée dans les versions 2.30.3, 2.31.2, 2.32.1, 2.33.2 et 2.34.2. Le libellé « dubious ownership » est apparu avec le correctif de suivi de CVE-2022-29187 (2.37.1, 2.36.2, 2.35.4 et les rétroportages correspondants) ; les versions corrigées antérieures affichent plutôt fatal: unsafe repository ('<path>' is owned by someone else). La documentation de référence de la configuration de Git décrit le paramètre safe.directory, qui pilote la liste d'autorisation correspondante ; Git ne lit ce paramètre que dans la configuration système, globale ou passée en ligne de commande, jamais dans la configuration propre au dépôt.

Pourquoi c'est important

Le contrôle se déclenche très souvent dans des configurations banales qui traversent pourtant une frontière d'UID : un dépôt cloné par une étape de build de conteneur puis monté en lecture/écriture dans une autre étape exécutée sous un utilisateur différent ; un runner de CI qui effectue le checkout avec un compte et exécute les étapes avec un autre ; un répertoire de l'hôte monté par bind mount dans un conteneur dont l'utilisateur ne correspond pas au propriétaire des fichiers sur l'hôte. Aucun de ces cas n'est une attaque, mais Git ne peut pas faire la différence au moment du contrôle ; il refuse donc de façon uniforme.

Comment l'appliquer

• Diagnostic : comparer ls -ld <repo> (propriétaire) avec id -u/id -un du compte qui exécute réellement Git ; git config --global --get-all safe.directory montre ce qui est déjà autorisé.
• Corrections, de la moins à la plus invasive :
  1. Faire confiance à ce seul dépôt : git config --global --add safe.directory /path/to/repo.
  2. Dans un job de CI éphémère où le chemin du checkout est imprévisible mais où tout l'environnement est jetable et à usage unique, git config --global --add safe.directory '*' est la méthode documentée pour désactiver complètement le contrôle (Git 2.35.3, 2.30.4 et versions ultérieures) ; à limiter à ce seul compte jetable.
  3. Mieux que les deux précédentes : supprimer la discordance d'UID elle-même. chown -R "$(id -u):$(id -g)" /path/to/repo (nécessite root ou les droits de propriétaire) avant d'exécuter Git, ou aligner l'utilisateur du conteneur sur le propriétaire du volume, traite la cause réelle au lieu de neutraliser le contrôle chaque fois qu'il se déclencherait de nouveau.
• Dangereux : définir safe.directory '*' dans un environnement durable, multi-utilisateur ou interactif. Cela rouvre exactement la faille que CVE-2022-24765 a fermée, pour tous les dépôts que le compte touchera un jour, y compris celui qu'un attaquant placerait plus tard.

Pièges

• La configuration --system applique la liste d'autorisation à tous les utilisateurs de l'hôte, pas seulement à celui qui l'a définie.
• Sous sudo, Git 2.37.0, 2.36.2, 2.35.4 et les versions ultérieures font aussi confiance aux dépôts appartenant à l'utilisateur indiqué dans SUDO_UID, mais Git peut lire un autre $HOME/.gitconfig que celui du shell interactif ; une entrée safe.directory ajoutée pour un compte ne s'applique donc pas à l'autre.