イメージの更新後にだけ、コンテナがroot所有のファイルを作成し始めるのはなぜですか？

イメージの更新後にコンテナが root 所有のファイルを作成する場合があります。これは、新しいイメージによって実行ユーザー、エントリーポイント、または起動時の所有権処理が変更されたことが原因です。

永続ボリューム自体は変更されていなくても、置き換え後のコンテナが異なる数値 UID で起動したり、初期化処理を一時的に root として実行したりすることがあります。新しいエントリーポイントによって、不足しているディレクトリの作成、設定の移行、権限の書き換え、以前のリリースで使用されていた PUID と PGID 変数の無視などが行われる場合もあります。再帰的な所有権変更を適用する前に、更新前から存在するファイル、起動時に作成されたファイル、実行中のアプリケーションが作成したファイルをそれぞれ1つずつ比較してください。

更新後のコンテナ起動時にのみ所有権が変更されることを確認する

スタックを停止し、既存ファイル1つとその親ディレクトリについて、数値 UID、GID、モード、ACL、タイムスタンプを記録します。更新後のコンテナをログを表示した状態で一度起動し、同じパスと新しく作成されたファイル1つを調べます。

Linux の chown システムコールは数値による所有権を変更します。そのため、決め手となる証拠は、ホストに表示されるユーザー名ではなく、起動前後の UID と GID です。

起動前から所有権が root になっている場合、更新が最初の原因ではありません。ファイルを書き込んだ更新処理、展開処理、バックアップからの復元、または管理者コマンドを調査してください。

更新前後のイメージユーザーを比較する

古いイメージと新しいイメージの設定、実効コンテナユーザー、エントリーポイント、コマンド、リリースノートを確認します。イメージが root、名前付きアカウント、または異なる数値 UID を宣言するようになっていないか記録してください。

Docker のドキュメントでは、USER 命令が実行時のアイデンティティを設定すると説明されています。これは、実行時のオーバーライドで置き換えられない限り、後続のイメージ命令、コンテナのエントリーポイント、コマンドに適用されます。

イメージ内のアプリケーションユーザー名が同じでも、数値 UID が変更されることがあります。ホストにマウントされたファイルはイメージ内のユーザー名ラベルではなく数値による所有権を保存するため、両方のイメージバージョン内の数値を比較してください。

新しいエントリーポイントが再帰的な chown を実行していないか確認する

起動ログ、リリースノート、エントリーポイントスクリプト、プロセストレースで、chown、権限修復、PUID、PGID、ユーザー移行、ディレクトリ初期化に関する処理を検索します。小さなスナップショットまたは使い捨てボリュームでテストしてください。

GNU Coreutils では、再帰的な chown は選択したディレクトリツリー全体の所有権を書き換える処理と定義されています。そのため、正常な既存ボリュームでも、新しいイメージの起動直後に変更されたように見えることがあります。

起動時の修復処理を無条件に削除しないでください。一部のイメージでは、新しく作成されたディレクトリにその処理が必要です。イメージが対応している場合は、文書化されたスキップフラグ、固定されたアプリケーション UID、またはより限定的なデータパスを優先してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Compose の user オーバーライドと削除された PUID・PGID 変数を監査する

更新前後のデプロイ済み Compose モデルを比較します。user:、環境変数、補助グループ、プロファイル、オーバーライドファイル、スタックマネージャーに保存された設定を含めて確認してください。

Kubernetes は、数値による実行時およびボリュームの明示的なアイデンティティを使用します。これは同じコンテナ境界の考え方を示しています。実行時のオーバーライドとボリューム所有権のポリシーは別々の設定であり、両者を一致させる必要があります。

古いイメージが PUID と PGID の変数を解釈していたものの、新しいリリースで変数が削除または改名された場合、変数が残っていてもプロセスを制御しなくなることがあります。実行中の UID を直接確認してください。

rootless とユーザーネームスペースの ID マッピングを考慮する

Docker が rootful、rootless、またはユーザーネームスペースの再マッピング付きで動作しているか記録します。コンテナから見える UID と、同じ inode のホストから見える所有者を比較してください。

Red Hat は、rootless コンテナが補助 UID および GID の範囲を使用すると説明しています。そのため、コンテナ内の root がホスト上の UID 0 として表示されるとは限らず、更新によってマッピングや実行モードの変更が明らかになる場合があります。

マッピングを理解しないまま rootless ボリュームをホストの root 所有に再帰的に変更しないでください。意図したコンテナのアイデンティティからデータにアクセスできなくなる可能性があります。

idmapped マウントまたはネットワークマウントによって表示される所有者が変わっていないか確認する

アプリケーションデータがローカルファイルシステム、idmapped マウント、NFS、SMB、FUSE、NAS 共有のいずれに保存されているか確認します。マウントオプションを記録し、サーバー、ホスト、コンテナから所有権を比較してください。

Linux カーネルの idmapped マウントモデルは、ファイルシステムの所有権とマウントの所有権を分離します。そのため、物理的な再帰的所有権変更を行わなくても、同じファイルが異なる ID で表示されることがあります。

更新後に表示される所有者だけが変わった場合、実行環境が異なる名前空間やマウントマッピングに入るようになっていないか確認します。すべての inode を書き換えるのではなく、マッピングを修正してください。

安定した実行時アイデンティティを復元し、次回の更新を検証する

所有権メタデータをバックアップし、アプリケーションを停止します。意図した数値 UID と GID を定義し、アプリケーションが所有するパスだけを修正して、固定したイメージと文書化されたユーザー設定で再デプロイします。

ZimaSpace のアプリケーションデータのコピー後のコンテナ所有権に関する記事では、コピーや移行が原因となるケースを扱っています。この記事では、置き換え後のイメージによって引き起こされた変更に焦点を当てています。

起動、アプリケーションによる書き込み、コンテナの再作成、ホストの再起動、管理されたイメージ更新のすべてで、広範な権限例外を設けることなく、文書化されたアイデンティティでファイルが作成されれば、修復は完了です。

よくある質問

root 所有のファイルがあることは、コンテナ全体が root で実行されている証拠ですか？

いいえ。エントリーポイントがボリュームを初期化するために短時間だけ root で実行され、その後、アプリケーションの起動前に権限を降格することがあります。

ボリューム全体に再帰的な chown を実行すべきですか？

意図した UID、共有パス、ACL、名前空間マッピングを特定する前には実行しないでください。広範な書き換えによって、データベース、共有メディア、rootless コンテナの所有権が壊れる可能性があります。

イメージの更新によってアプリケーション UID が変わることはありますか？

はい。メンテナーがイメージのユーザーを変更したり、アカウントデータベースを再構築したり、PUID または PGID の設定名を変更したり、起動時の所有権移行処理を追加したりすることがあります。