Git: fatal: detected dubious ownership in repository

안녕하세요, BlueByte입니다. 어제까지 잘 되던 저장소에서 — 컨테이너 안에서, sudo로, 혹은 새로 마운트한 디스크에서 — git status를 실행했더니 fatal: detected dubious ownership in repository로 멈추는 경우가 있습니다. 망가진 것은 없습니다. 커밋은 그대로이고, Git이 명령을 실행한 사용자와 다른 사용자가 소유한 저장소를 읽지 않겠다고 거절하는 것뿐입니다. 오늘은 이 메시지가 뜻하는 것, Git이 이렇게 동작하는 이유, 어떤 불일치인지 확인하는 방법, 원인별 해결, 그리고 예방까지 하나씩 짚어보겠습니다.

메시지의 모양과 예전 문구

Linux와 macOS에서는 fatal 한 줄과 제안 명령이 출력되고, Git은 종료 코드 128로 끝납니다:

fatal: detected dubious ownership in repository at '/srv/app'
To add an exception for this directory, call:
 
	git config --global --add safe.directory /srv/app

Git for Windows는 경로의 소유자와 현재 사용자도 함께 보여주며, 모양은 다음과 같습니다:

'C:/work/app' is owned by:
	BUILTIN/Administrators (S-1-5-32-544)
but the current user is:
	WORKPC/alex (S-1-5-21-...)

Git 2.35.2부터 2.37까지는 같은 검사가 예전 문구 unsafe repository ('/srv/app' is owned by someone else)로 출력됩니다. detected dubious ownership 문구는 2.38부터입니다. 검사도 해결책도 같습니다.

Git이 자기 소유가 아닌 저장소를 거절하는 이유

이 검사는 2022년 4월 Git 2.35.2에서 수정된 CVE-2022-24765에서 나왔습니다. 저장소 설정은 Git이 프로그램(hook, core.fsmonitor, pager)을 실행하게 만들 수 있어서, 공유 머신에서 다른 사용자가 심어 둔 .git 디렉터리가 근처에서 git status를 치는 순간 내 권한으로 코드를 실행할 수 있었습니다. 그 릴리스부터 Git은 작업 트리와 .git 디렉터리의 소유자를 명령을 실행하는 사용자와 비교하고, 다르면 멈춥니다.

Linux와 macOS에서는 숫자 사용자 ID로 비교합니다. root만 예외입니다. root 소유 저장소는 통과하고, sudo로 실행하면 sudo가 SUDO_UID에 저장한 UID도 인정합니다. 예외 목록은 safe.directory에 두며, Git은 이 설정을 보호된 설정 — system, global, 명령줄 — 에서만 읽습니다. 저장소 자신의 .git/config는 읽지 않는데, 바로 그 파일을 아직 신뢰하지 않기 때문입니다.

소유자와 사용자가 어긋나는 흔한 경로

• 컨테이너나 CI 작업이 root 또는 고정 UID로 실행되는데, 바인드 마운트한 체크아웃은 호스트 사용자 소유인 경우.
• sudo git clone으로 받은 저장소를 일반 사용자로 쓰거나, 그 반대인 경우.
• 서비스 계정(www-data, jenkins)이 관리자가 만든 디렉터리에서 Git을 실행하는 경우.
• Windows에서 외장·네트워크 드라이브의 저장소, 또는 관리자 권한 프롬프트로 만들어 Administrators 소유가 된 폴더.

먼저 소유자와 Git을 실행하는 사용자를 비교하기

파일시스템과 Git에 물어봅니다:

stat -c '%U %u %n' /srv/app /srv/app/.git
id -un; id -u
git config --show-scope --get-all safe.directory

직접 재현해 보니, ubuntu(UID 1001) 소유 저장소에서 Git을 nobody로 실행했을 때 stat은 두 경로 모두 ubuntu 1001을, id -u는 65534를 출력했습니다 — 명백한 불일치입니다. 마지막 명령의 결과가 비어 있으면 Git이 신뢰하는 어느 범위에도 예외가 설정되지 않았다는 뜻입니다.

원인별 해결: 저장소를 소유하거나, 의도적으로 신뢰하거나

파일이 내 것이어야 한다면 검사를 끄지 말고 소유권을 바로잡습니다:

sudo chown -R "$(id -u):$(id -g)" /srv/app
git -C /srv/app status
# On branch main

불일치가 의도된 것이라면(공유 저장소, CI 컨테이너), Git을 실행하는 사용자의 global 설정에 정확한 경로를 추가합니다:

git config --global --add safe.directory /srv/app
git config --show-scope --get-all safe.directory
# global	/srv/app

명령 한 번만이라면 명령줄 범위도 됩니다: git -c safe.directory=/srv/app status. /srv/app/.git/config에 적는 것은 소용없습니다 — 직접 해 보니 문서에 적힌 대로 Git이 거기 값은 무시했습니다.

한 디렉터리 아래 모든 저장소를 신뢰하려면 Git 2.46 이상에서 safe.directory=/srv/*처럼 끝에 /*를 붙일 수 있습니다. 이전 버전은 이를 아무것도 맞지 않는 문자 그대로의 경로로 취급합니다 — 제 2.43 환경에서는 오류가 그대로였습니다 — 그러니 먼저 git --version을 확인해 보세요. 값 * 하나는 검사를 완전히 끕니다. 다른 누구도 디스크에 쓸 수 없는 일회용 컨테이너에서만 쓰십시오.

따라 해 보기: 같은 저장소, sudo 유무에 따라

ubuntu 소유 저장소를 sudo를 통해 root로 실행합니다:

sudo git -C /srv/app status
# On branch main
sudo env -u SUDO_UID git -C /srv/app status
# fatal: detected dubious ownership in repository at '/srv/app'

첫 번째는 Git이 SUDO_UID를 읽어 소유자 UID를 찾았기 때문에 됩니다. 이 변수를 빼면 — root로 도는 컨테이너 안이나 su - 이후가 사실상 이 상태입니다 — 같은 명령이 실패합니다. CI에서 보고되는 사례 대부분이 이 패턴입니다. 작업의 Git이 체크아웃 소유자와 한 번도 맞은 적 없는 사용자로 실행되는 것입니다. 컨테이너를 체크아웃의 UID로 실행하거나, 설정 단계에 git config --global --add safe.directory "$PWD"를 추가하세요.

끝까지 확인하고 그 상태를 유지하기

git status 다음에 echo $?를 실행합니다. 브랜치 정보와 0이 나오면 끝입니다. 유지하려면 클론은 그것을 쓰는 계정이 소유하게 두고, 일상 작업에 sudo git을 피하고, safe.directory 줄을 정확한 체크아웃 경로와 함께 컨테이너 이미지나 CI 설정에 넣고, *에 기대기보다 경로를 하나씩 나열하세요.

권한 오류, "not a git repository"와 다른 점

error: insufficient permission for adding an object to repository database .git/objects는 쓰기 실패입니다. Git은 저장소를 신뢰했고, 운영체제가 쓰기를 거부한 것입니다. fatal: not a git repository (or any of the parent directories): .git은 Git이 .git을 아예 찾지 못했다는 뜻입니다. dubious ownership은 그 사이에 있습니다. Git이 저장소를 찾았지만 일부러 읽기를 거절한 것입니다.

다음에 이 오류를 만나면 이 순서를 거꾸로 따라가 보세요. stat과 id -u를 비교하고, 소유자와 사용자 중 어느 쪽이 틀렸는지 판단한 뒤, 그다음에야 정확한 경로로 safe.directory를 꺼내 드세요.