テクノロジー · 実用ガイド
Git の「detected dubious ownership」：safe.directory を追加する前に所有者境界を確認する
致命的エラーを単なる警告ではなく、実行主体と所有者の不一致として扱います。Git の実行ユーザー、リポジトリ所有者、マウント境界、設定スコープを確認してから、狭い例外だけを検討します。
作業ツリーが別の主体に所有されていると、Git は明示的に信頼されたパスでない限り、そのリポジトリ設定を読みません。安全な修復は、Git を実行するユーザーと正規パスの所有者を特定し、誤った所有権は直し、意図的な共有だけに一つの例外を追加することです。
1. 失敗した主体と正規パスを記録する
失敗した同じシェル、サービス、コンテナ、CI ステップで再現します。有効ユーザー、Git が示したパス、正規化した作業ツリーパスを記録します。Unix 系では id -u と id -g をリポジトリおよび各親ディレクトリの所有者と比較し、Windows では同じ Git クライアント文脈で所有者 SID を確認します。GUI、sudo、サービス、コンテナが同じユーザーや設定を使うとは限りません。
2. 変更前に不一致を分類する
復元、管理者による clone、ディスク移動、root ビルドで所有者が誤ったなら、所有者を直すか本来のユーザーで実行します。共有のため意図的に異なるなら、所有者は維持し正確な例外を一つ追加します。ファイルシステムが不安定な所有者情報を返す場合は、繰り返し証拠を取り、マウント直下ではなく一段下のパスや親ディレクトリのマウントを試します。
3. 失敗プロセスが読む設定を確認する
--global はそのコマンドを実行したユーザーの設定へ書きます。別のサービスアカウント、コンテナユーザー、CI プロセスは別の HOME を読むことがあります。失敗文脈で git config --show-origin --get-all safe.directory を実行し、値と設定ファイルを確認します。system スコープは管理者がマシン全体の方針を意図する場合だけ使います。ローカル設定でリポジトリ自身を安全にすることはできません。
4. 最小範囲の修復を行う
所有者が誤りなら、無関係な親ディレクトリの権限を広げず、リポジトリツリーだけを本来のアカウントへ戻します。共有が意図的なら、Git を実行する主体の保護された設定に正規パスを一つ追加します。* は全リポジトリを安全扱いにする完全な無効化です。末尾の /* も配下すべてを信頼するため、管理された共有ルートに限ります。
5. 元の操作と入れ子リポジトリを再試験する
元のプロセスユーザーで git status と失敗した操作を再実行し、サブモジュール、worktree、入れ子の各パスも別々に確認します。root や別 HOME で成功しても証明になりません。有効ユーザーと show-origin を再確認し、狭いパスで直った後は古い例外やワイルドカードを削除します。共有を信頼する理由も短く記録します。
警告を尊重すべき理由
この所有者境界は CVE-2022-24765 を受けて導入されました。GitHub は、共有マシンで攻撃者が親ディレクトリに .git を置き、コマンド実行につながる設定を読ませ得ると説明しています。問うべきは「どう消すか」ではなく、「誰が所有し、なぜ正当で、例外をどこまで狭くできるか」です。
