Podman Quadletで削除した権限が残るときの確認手順

Podman QuadletでWebアプリを管理し、不要な追加権限やホストのマウントを削るときは、編集元の設定だけで作業を終えないでください。CVE-2026-19730では、podman quadlet install --replaceで短いファイルへ置き換えた際、旧ファイルの末尾が残り、削除したはずの設定が使われる可能性があります。修正済みPodmanへ更新し、保存先と生成ユニット、稼働コンテナまで照合することが対応の軸です。

本稿は2026年10月30日に公式資料を確認した実践解説です。8月公開の既知の問題を扱い、新しい脆弱性の速報ではありません。Podman開発元の勧告と現行ドキュメントを基に、Linuxのrootless構成で単一のweb.containerを管理する作業に絞ります。コマンドは確認案であり、執筆環境でPodmanの再現試験や動作測定を行ったものではありません。

短くした設定の末尾に旧内容が残る

開発元によると、この問題はPodman 5.7.0で導入されました。元のQuadletが置換後より大きい場合にファイルが切り詰められず、以前の末尾が保持されます。多くは不正な構文として現れますが、残った内容を含めても有効な設定なら、追加権限などが残存し得ます。インストール操作を行えることと、期待した制限が反映されたことは別です。

Red HatのCVE説明は、reflinkによるコピーが失敗し、通常コピーへフォールバックする経路で、既存ファイルを切り詰めない書き込みになる条件を説明しています。ファイルシステムの種類だけで一律に対象外とせず、使用版と配布元の修正情報、実際の保存結果から判断します。

勧告には、末尾のAddCapabilityを消しても残る例と、Volume Quadletの追加マウントが残る例があります。後者では、本来見せない内容をコンテナへ露出させ、後にイメージが侵害された際の情報取得につながる可能性があります。一方、置換する利用者が既に設定を読めるため、設定ファイル自体の情報漏えいを直接の影響とはしていません。

開発元の評価はModerate、CVSS v3.1は4.2です。認証不要の遠隔RCEとは異なりますが、権限削減を意図した保守作業の結果が変わるため、Webアプリの実行境界を管理する担当者に関係します。公開された再現情報と、実環境での悪用確認も区別する必要があります。

上流版と配布元の修正を分けて確認する

開発元は5系の修正先に5.8.6を示し、6.0.0には修正が含まれるとしています。まずpodman --versionで実行するプログラムを確認し、パッケージ管理側の完全な版番号と照合します。6.0.0までの全系列が同じように影響する、という意味ではありません。

RHSA-2026:70201は、RHEL 10向けの9月22日付更新で本CVEを修正対象に含め、podman-5.8.2-9.el10_2を掲載しています。修正のバックポートがあるため、上流版5.8.6との数字の大小だけでは判定できません。別のRHEL系列や他ディストリビューションへ、このパッケージ番号を流用しないでください。

更新しても、以前の置換で残った末尾や、そこから起動したコンテナが自動的に正しい設定へ戻るとは期待できません。インストール処理の修正と、現在配置されているファイルを承認済み内容へ直す作業を分けます。配備サーバーと本番ホストで別のPodmanを使う場合も、実際に置換を行う側を確認します。

対象ユーザーと読み込まれる原本を特定する

Quadlet公式仕様では、rootlessの検索先に$XDG_CONFIG_HOME/containers/systemd/または~/.config/containers/systemd/などが含まれます。rootfulには/run、/etc、/usr/share配下の別の検索先があります。以下をrootのユニットへそのまま適用せず、サービスを所有する利用者として作業します。

例は単独配置の通常ファイルweb.containerを対象とし、アプリケーション名によるサブディレクトリ、テンプレート、シンボリックリンクを使わない前提です。既存の配備記録やinstallの出力から実際の保存先を特定してください。別環境のパスを未確認のまま転用しないことが重要です。

podman --version
podman quadlet install --help
systemctl --user cat web.service
systemctl --user show web.service -p FragmentPath -p DropInPaths -p ExecStart

web.containerからは通常web.serviceが生成され、コンテナ名は既定でsystemd-webです。ContainerNameがあればその指定を確認します。systemctl catで見る生成ユニットと、編集するQuadlet原本は別です。生成側を直接編集しても次回の生成で失われる可能性があるため、修正元を取り違えないでください。

web.container.dのようなdrop-inと共通のcontainer.dも確認します。本体から削除しても別設定から追加されれば、末尾残存とは別の原因で権限が残ります。優先される同名ファイル、Quadletのdrop-in、通常のsystemd側の追加設定を整理し、変更の根拠を残します。

再読込の前に保存先との一致を確認する

quadlet installの公式マニュアルでは--reload-systemdの既定値はtrueです。修正済みPodmanで対応オプションを確認し、保存と再読込の間で比較するならfalseを指定します。次はreviewed/web.containerを承認済み原本とした例です。配置先が異なる場合は正しい通常ファイルへ変更します。

quadlet_candidate="$PWD/reviewed/web.container"
quadlet_destination="${XDG_CONFIG_HOME:-$HOME/.config}/containers/systemd/web.container"

podman quadlet install --replace --reload-systemd=false "$quadlet_candidate"
cmp -- "$quadlet_candidate" "$quadlet_destination"
wc -c -- "$quadlet_candidate" "$quadlet_destination"

各コマンドの終了結果を確認して進めます。cmpは内容が同じなら終了コード0で通常は何も出力せず、差があれば反映を止めます。サイズ一致だけでは内容一致を証明できないため、wcは補助です。配置先の誤り、読取権限不足、ファイルが存在しない場合も成功扱いにしないでください。

修正版へ直ちに移れない場合、開発元はQuadletディレクトリへの手動コピーを回避策に挙げています。保存先、所有者、アクセス権、リンクの有無を確認し、切り詰めを伴う通常のファイルコピーで承認済み原本を反映した後、同じ比較を行います。アプリケーション単位の管理情報まで単純コピーで再現できるとは限らず、本稿の前提外では正式な配備手順を優先します。

変更前の原本は検索対象外に安全に保管します。別名の.containerとして同じ検索先へバックアップすると、別サービスとして読み込まれるおそれがあります。設定中の秘密の値や内部パスを、比較ログや公開の質問サイトへそのまま出さないようにします。

生成ユニットで追加権限とマウントを点検する

保存先が一致したら、サービスを起動する前に生成結果を確認します。公式は生成エラーの確認に次のdryrunとsystemd-analyzeを案内しています。ジェネレーターの配置場所やsystemdの対応オプションは配布元で確認し、エラーがあれば起動へ進みません。

/usr/lib/systemd/system-generators/podman-system-generator --user --dryrun
systemd-analyze --user --generators=true verify web.service

Container Quadletの仕様では、AddCapabilityは--cap-add、Volumeは--volume、ReadOnlyは--read-onlyへ対応します。生成されたExecStartも読み、削除した追加権限やホストパスがないか比較します。AddCapabilityがないことは全capabilityがゼロという意味ではなく、既定の権限と追加分を分けて評価します。

構文検証の成功は、マウントの必要性やアプリの安全性まで保証しません。読ませるホスト領域、書き込ませる領域、追加権限を、承認した変更項目と対にして確認します。未知の設定項目で生成されないなら、古いPodmanが新オプションに対応していない可能性もあり、資料の版と稼働版を照合します。

再読込と再起動を区別して稼働実体を見る

内容と生成結果を確認した後、承認した保守時間にdaemon-reloadと対象サービスの再起動を行います。daemon-reloadだけで稼働中コンテナの権限やマウントが変わったとは判断できません。次の操作には再起動による停止影響があるため、必要な調整を先に終えます。

systemctl --user daemon-reload
systemctl --user cat web.service
systemctl --user restart web.service
systemctl --user status web.service
podman inspect --type container systemd-web

podman inspectは構成情報をJSONで表示します。対象名を明示し、意図しない別コンテナを選ばないようにします。Mountsやcapabilityに関する情報を変更前と照合し、イメージと起動結果も確認します。環境変数などの秘密が含まれ得るため、記録は必要な項目に絞りアクセスを制限してください。

正常なHTTP応答に加え、アップロードやバッチなど利用する機能も試験します。不要なマウントがないことと、必要な永続データを扱えることを両方確認します。失敗したからといって広い権限を一括で戻さず、起動ログ、所有者、パス、削除した権限との関係を順に調べます。

不一致が起きた段階から切り分ける

原本と保存先が違えば配置処理、保存先は一致するが生成結果が違えば検索先やdrop-in、生成結果は正しいが稼働状態が違えば再起動対象やコンテナ名の順で調べます。これにより、末尾残存と設定の重ね合わせ、反映漏れを混同しにくくなります。

完了記録には、修正済みPodmanの根拠、対象ユーザー、配置先、原本との比較、生成時の確認、再起動後の確認を残します。切り戻しでも旧ファイルの危険な追加権限を無条件に復元しないようにします。CVE修正の適用と、削減した権限が実際に消えたことの二つを確認して、この作業を完了と判断してください。

関連記事

Webアプリのコンテナを非rootで動かす設計ではDockerの読み取り専用化と書き込み先を説明しています。本稿はPodmanの配置結果とsystemdへの反映が対象で、Docker Composeの操作をそのまま置き換えるものではありません。