How can an agent resolve this problem? git 'fatal: detected dubious ownership in repository' (CVE-2022-24765): repo owner != git's user — use safe.directory (system-level in containers/CI)
Cause: git 2.35.2 (security fix for CVE-2022-24765) refuses to operate in a repository whose on-disk owner differs from the current process user, to prevent malicious config/hooks on multi-user systems. In containers/CI the mounted workspace UID (e.g. host user 1000) differs from git's user (often root), so the check trips. GitHub Actions `actions/checkout` sets `safe.directory` for the main repo based on HOST ownership; container jobs (git runs as root inside) and custom scripts or additional clones still fail.
Recommended action:
1) Trust the path: `git config --global --add safe.directory <path>` for the current user. In containers/CI where git runs as root or a different user, `--global` (which belongs to one user) may not apply — use system scope: `git config --system --add safe.directory '*'` (or a specific path). Wildcard `'*'` needs git >= 2.36.
2) Dockerfile: `RUN git config --system --add safe.directory '*'`. CI job: run `git config --global --add safe.directory "$GITHUB_WORKSPACE"` (or `'*'`) BEFORE any git command, and install git before the checkout step.
3) Or run the container as the workspace owner: `docker run --user $(id -u):$(id -g) ...` (also gives correct ownership to files the build writes back to the mount).
Misleading approaches: using `--global` when git runs as root (the config belongs to a different user's HOME); adding safe.directory AFTER the failing step; assuming the repository is corrupted.
Security note: `safe.directory '*'` disables the ownership check for those paths — acceptable for ephemeral, single-tenant CI/containers you control; understand CVE-2022-24765 before using it on multi-user machines.
Version/fix status: intended git behavior since 2.35.2; the fix is trusting the path at the correct scope (usually `--system` in containers).
Sources:
- https://github.com/actions/runner/issues/2033
- https://support.atlassian.com/bitbucket-cloud/kb/git-command-returns-fatal-error-detected-dubious-ownership/
Unknowns: whether `--global` vs `--system` is needed depends on which user runs git — check `whoami` inside the job/container.
Evidence boundary: public GitHub issue text + vendor KB + git's documented CVE-2022-24765 behavior; no independent reproduction claimed here.
Problem details
- Observed symptom
- A git command aborts (exit code 128) with: `fatal: detected dubious ownership in repository at '<path>'` `To add an exception for this directory, call:` ` git config --global --add safe.directory <path>` Sometimes followed by `fatal: not a git repository (or any parent up to mount point /) ... GIT_DISCOVERY_ACROSS_FILESYSTEM not set`.
- Context
- git >= 2.35.2 running against a repository whose on-disk owner differs from the user running git. Extremely common in Docker containers (workspace mounted with the host UID while git runs as root) and CI container jobs.
- Environment
- State
- partial
- Text
- Containers and CI where the mounted repo UID differs from the git process user; git >= 2.35.2.
- Facts
- Git
- >= 2.35.2 (CVE-2022-24765); wildcard safe.directory '*' since 2.36
- Typical
- container runs as root, workspace owned by host uid 1000
- Gha
- actions/checkout sets safe.directory from HOST ownership, so container jobs/custom scripts still fail
- Symptom signature
- Tool product
- Git
- Component
- setup_git_directory ownership check (safe.directory, CVE-2022-24765)
- Operation
- any git command in a repo owned by another user
- Error code
- fatal / exit 128
- Literal error text
- fatal: detected dubious ownership in repository at '<path>' || To add an exception for this directory, call: git config --global --add safe.directory <path>
- Version info
- git >= 2.35.2; safe.directory wildcard '*' since 2.36
- Literal source
- contributor_supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Add the repo to safe.directory at the right scope (system-level in containers/CI) or run git as the workspace owner
git blocks repos owned by another user. Trust the path with safe.directory using --system in containers, or match the container user to the mount UID.
- Problem id
- 09aedbd0-701c-4888-bec5-447a53fc066c
- Proposed action
- 1) `git config --system --add safe.directory '*'` in the Docker image or container CI job (git >= 2.36 for '*'). 2) Or per-repo: `git config --global --add safe.directory "$GITHUB_WORKSPACE"` BEFORE git runs (for the user git actually runs as). 3) Or run the container as the mount owner: `docker run --user $(id -u):$(id -g) ...`.
- Applicability
- State
- partial
- Text
- git >= 2.35.2 in containers/CI where the repo owner differs from git's user.
- Limitations
- State
- known
- Text
- safe.directory '*' weakens the ownership check for those paths; use only where you control the repos.
- Success criteria
- Text
- git commands run without 'detected dubious ownership' (exit 0).
- Risk notes
- Text
- Do not use wildcard safe.directory on shared multi-user machines.
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.