Git « dubious ownership » : corriger safe.directory sans désactiver la protection

ParKelvin Carretero-Corrales

Vous lancez git status et Git répond detected dubious ownership in repository ? Ce message n’indique pas un dépôt corrompu. Git constate que le dépôt appartient à un autre utilisateur que celui qui exécute la commande et refuse de lire sa configuration tant que cette différence n’est pas expliquée.

La bonne réponse n’est généralement pas safe.directory=*. Commencez par identifier l’utilisateur effectif et le propriétaire du dépôt. Corrigez la propriété si elle est accidentelle ; ajoutez une exception limitée au chemin exact seulement si le partage est volontaire et que le dépôt est fiable.

Pourquoi Git bloque-t-il le dépôt ?

Depuis Git 2.35.2, le contrôle de propriété empêche par défaut l’exécution de commandes dans un dépôt possédé par un autre utilisateur. Il a été introduit après la vulnérabilité CVE-2022-24765 : sur une machine multiutilisateur, un attaquant pouvait placer un répertoire .git dans un emplacement parent partagé et amener Git à lire une configuration malveillante.

Le risque ne se limite pas à afficher une mauvaise branche. Certaines options Git peuvent déclencher des programmes externes ou des hooks. Refuser un dépôt dont le propriétaire est inattendu constitue donc une frontière de confiance, pas une gêne arbitraire.

Étape 1 : identifier l’utilisateur et le propriétaire réels

Ne copiez pas immédiatement la commande proposée par le message d’erreur. Relevez d’abord le chemin absolu du dépôt et l’identité sous laquelle Git s’exécute.

Sous Linux

whoami
id
pwd
stat -c '%U:%G %n' /chemin/absolu/du/depot
git config --show-origin --get-all safe.directory

Sous macOS

whoami
id
pwd
stat -f '%Su:%Sg %N' /chemin/absolu/du/depot
git config --show-origin --get-all safe.directory

Sous Windows PowerShell

whoami
(Get-Acl 'C:\chemin\absolu\du\depot').Owner
git config --show-origin --get-all safe.directory

Comparez l’utilisateur retourné par whoami avec le propriétaire du dossier. Vérifiez également l’origine des éventuelles entrées safe.directory : --show-origin indique le fichier de configuration qui les fournit.

Étape 2 : choisir la correction adaptée

Cas A — le propriétaire est incorrect par accident

C’est fréquent après avoir cloné, extrait ou manipulé le projet avec sudo. Si le dépôt est strictement personnel, redonnez-le à votre compte plutôt que de contourner le contrôle. Sous Linux, après avoir vérifié deux fois le chemin :

sudo chown -R "$USER":"$(id -gn)" -- /chemin/absolu/du/depot

N’exécutez pas cette commande sur un dépôt système, un partage d’équipe ou un chemin dont vous n’êtes pas certain. Une modification récursive du mauvais dossier peut casser des permissions légitimes. Sous macOS, Linux ou Windows, la logique reste la même : corriger le propriétaire uniquement lorsque cette propriété différente est réellement une erreur.

Cas B — le dépôt est volontairement partagé

Un dépôt monté depuis un NAS, ouvert par plusieurs comptes ou créé par un utilisateur de service peut légitimement avoir un autre propriétaire. Si vous avez vérifié sa provenance et son contenu, ajoutez uniquement son chemin absolu à la configuration protégée de votre compte :

git config --global --add safe.directory /srv/projets/mon-depot

Sous Windows, utilisez un chemin explicite et mettez-le entre guillemets :

git config --global --add safe.directory "C:/Users/nom/projets/mon-depot"

safe.directory peut contenir plusieurs valeurs. Git n’accepte ce réglage que depuis une configuration protégée, notamment globale ou système ; un dépôt non fiable ne peut donc pas s’auto-déclarer sûr dans son propre fichier .git/config. Pour une règle commune à plusieurs comptes, la configuration système peut convenir, mais elle doit être décidée et appliquée par l’administrateur.

Cas C — le dépôt vient d’un conteneur, de WSL ou d’un volume monté

Dans un conteneur, l’UID et le GID du processus peuvent ne pas correspondre à ceux du propriétaire sur l’hôte. Avec WSL, NFS, SMB ou un NAS, le montage peut aussi traduire les identités différemment. La correction durable consiste à aligner l’utilisateur du conteneur, les UID/GID ou les options de montage. Une exception ciblée reste acceptable pour un espace de travail connu, mais elle ne doit pas masquer un volume accessible à des utilisateurs non fiables.

Pourquoi éviter safe.directory=* ?

La valeur * indique à Git de considérer tous les dépôts comme sûrs, quel que soit leur propriétaire. Elle désactive donc précisément le contrôle qui vient de vous alerter. Sur une machine personnelle isolée, cela peut sembler pratique ; sur un serveur, un poste partagé, un runner CI réutilisé ou un dossier inscriptible par d’autres comptes, l’exception devient beaucoup trop large.

Si une ancienne procédure a ajouté cette valeur, listez les règles, retirez les entrées globales, puis recréez seulement les exceptions nécessaires :

git config --global --get-all safe.directory
git config --global --unset-all safe.directory
git config --global --add safe.directory /chemin/absolu/du/depot-fiable

La commande --unset-all supprime toutes les valeurs globales de cette clé. Notez donc les exceptions légitimes avant de l’exécuter. Une règle définie au niveau système devra être examinée séparément avec --show-origin.

Vérifier sans élargir la confiance

Après la correction, testez le dépôt explicitement plutôt que de changer de nombreux réglages à la fois :

git -C /chemin/absolu/du/depot status
git config --show-origin --get-all safe.directory

Si l’erreur revient, ne passez pas directement à sudo git. Cela change le contexte d’exécution, peut créer des fichiers appartenant à root et rend le problème plus difficile à comprendre. Revenez aux trois informations de base : utilisateur effectif, propriétaire réel et type de montage.

Checklist de décision

  • Le dépôt devrait vous appartenir : corrigez le propriétaire après validation du chemin.
  • Le dépôt est partagé et fiable : ajoutez son chemin exact à safe.directory.
  • Le dépôt est sur un volume ou dans un conteneur : alignez les identités et les options de montage si possible.
  • Vous ne connaissez pas l’origine du dépôt : ne l’ajoutez pas à la liste sûre avant inspection.
  • Une règle * existe : retirez-la et remplacez-la par des exceptions minimales.

Conclusion

L’erreur « dubious ownership » est un signal de sécurité utile. Une correction propre consiste à expliquer l’écart de propriétaire, pas à déclarer tous les dépôts fiables. En gardant une liste safe.directory courte et explicite, vous résolvez le blocage sans supprimer la protection sur le reste de la machine.

Sources

Publications similaires