O erro "detected dubious ownership in repository" do Git e a correção com safe.directory

O que é

fatal: detected dubious ownership in repository at '<path>' é uma mensagem emitida pelo próprio Git, seguida de To add an exception for this directory, call: e de uma linha git config já pronta, quando um comando Git acessa um repositório cujo worktree ou diretório .git não pertence ao usuário que está executando o Git. O Git 2.35.2 introduziu essa verificação como correção do CVE-2022-24765: antes dela, um repositório colocado por outro usuário em um local compartilhado ou com permissão de escrita para todos (um diretório temporário, um volume montado) podia conter uma configuração que executava código escolhido pelo atacante assim que o processo Git de outra pessoa entrasse nele. A mesma verificação foi incluída nas versões 2.30.3, 2.31.2, 2.32.1, 2.33.2 e 2.34.2. A redação "dubious ownership" surgiu com a correção complementar do CVE-2022-29187 (2.37.1, 2.36.2, 2.35.4 e backports equivalentes); as versões corrigidas anteriores exibem fatal: unsafe repository ('<path>' is owned by someone else). A referência de configuração do próprio Git documenta a opção safe.directory, que controla a lista de exceções resultante; o Git só a lê da configuração do sistema, global ou da linha de comando, nunca da configuração do próprio repositório.

Por que importa

A verificação dispara constantemente em cenários comuns que, mesmo assim, atravessam uma fronteira de UID: um repositório clonado por uma etapa de build de contêiner e montado com leitura e escrita em outra etapa executada por um usuário diferente; um runner de CI que faz o checkout com uma conta e executa os passos com outra; um diretório do host montado por bind mount em um contêiner cujo usuário não corresponde ao dono dos arquivos no host. Nenhum desses casos é um ataque, mas o Git não consegue distingui-los de um ataque dentro da verificação, então recusa todos igualmente.

Como aplicar

• Diagnóstico: compare ls -ld <repo> (dono) com id -u/id -un da conta que realmente executa o Git; git config --global --get-all safe.directory mostra o que já está na lista de exceções.
• Correções, da menos para a mais invasiva:
  1. Confiar neste repositório específico: git config --global --add safe.directory /path/to/repo.
  2. Em um job de CI efêmero em que o caminho do checkout é imprevisível, mas todo o ambiente é descartável e de finalidade única, git config --global --add safe.directory '*' é a forma documentada de desativar completamente a verificação (Git 2.35.3, 2.30.4 e posteriores); restrinja isso apenas àquela conta descartável.
  3. Melhor que as duas anteriores: eliminar a própria divergência de UID. chown -R "$(id -u):$(id -g)" /path/to/repo (exige root ou direitos de propriedade) antes de executar o Git, ou alinhar o usuário do contêiner com o dono do volume, resolve a causa real em vez de suprimir a verificação toda vez que ela voltar a disparar.
• Inseguro: definir safe.directory '*' em um ambiente de longa duração, multiusuário ou interativo. Isso reabre exatamente a brecha que o CVE-2022-24765 fechou, para todos os repositórios que a conta venha a tocar, inclusive um que um atacante plante depois.

Armadilhas

• A configuração --system aplica a lista de exceções a todos os usuários do host, não apenas a quem a definiu.
• Sob sudo, o Git 2.37.0, 2.36.2, 2.35.4 e posteriores também confiam em repositórios pertencentes ao usuário indicado em SUDO_UID, mas ele pode ler um $HOME/.gitconfig diferente do shell interativo, de modo que uma entrada safe.directory adicionada para uma conta não vale para a outra.