Git's "detected dubious ownership in repository" error and the safe.directory fix

What it is

fatal: detected dubious ownership in repository at '<path>' is emitted by Git itself, followed by To add an exception for this directory, call: and a ready-made git config line, when a Git command touches a repository whose worktree or .git directory is not owned by the user running Git. Git 2.35.2 introduced the check as the fix for CVE-2022-24765: before it, a repository placed by another user in a shared or world-writable location (a temp directory, a mounted volume) could carry config that ran attacker-chosen code once someone else's Git process entered it. The same check shipped in 2.30.3, 2.31.2, 2.32.1, 2.33.2 and 2.34.2. The "dubious ownership" wording arrived with the CVE-2022-29187 follow-up (2.37.1, 2.36.2, 2.35.4 and matching backports); earlier fixed releases print fatal: unsafe repository ('<path>' is owned by someone else) instead. Git's own configuration reference documents the safe.directory setting that controls the resulting allow-list; Git only reads it from system, global or command-line config, never from the repository's own config.

Why it matters

The check fires constantly in unremarkable setups that still cross a UID boundary: a repository cloned by one container build stage and mounted read/write into another running as a different user; a CI runner that checks out as one account and runs steps as another; a host directory bind-mounted into a container whose user does not match the host file owner. None of these are attacks, but Git cannot tell the difference from inside the check, so it refuses uniformly.

How to apply

• Diagnose: compare ls -ld <repo> (owner) against id -u/id -un of the account actually running Git; git config --global --get-all safe.directory shows what is already allow-listed.
• Fixes, least to most invasive:
  1. Trust this one repository: git config --global --add safe.directory /path/to/repo.
  2. In an ephemeral CI job where the checkout path is unpredictable but the whole environment is disposable and single-purpose, git config --global --add safe.directory '*' is the documented way to opt out of the check completely (Git 2.35.3, 2.30.4 and later); keep it scoped to that throwaway account only.
  3. Better than either: remove the UID mismatch itself. chown -R "$(id -u):$(id -g)" /path/to/repo (needs root or ownership rights) before running Git, or align the container's user with the volume's owner, fixes the actual cause instead of suppressing the check every time it would fire again.
• Unsafe: setting safe.directory '*' in a long-lived, multi-user, or interactive environment. That re-opens exactly the hole CVE-2022-24765 closed, for every repository the account will ever touch, including one an attacker plants later.

Pitfalls

• --system config applies the allow-list to every user on the host, not just the one who set it.
• Under sudo, Git 2.37.0, 2.36.2, 2.35.4 and later also trust repositories owned by the user in SUDO_UID, but it may read a different $HOME/.gitconfig than the interactive shell, so a safe.directory entry added for one account does not apply to the other.