Podmanルートレスコンテナでのファイルとデバイスの使用

Podmanユーザーが抱えている重要な問題の1つは、ホストからは使用できるが、オブジェクトをコンテナーにボリュームマウントしても、コンテナー内では使用できないファイルやデバイスにアクセスすることです。

この場合、補足的なグループアクセスについて見ていきます。多くの場合、システムは、特定のユーザーグループのみがアクセスできるファイルとデバイスでセットアップされます。たとえば、私はホイールにいますシステム上のグループ。これにより、ユーザーはいくつかの管理コントロールにアクセスできます。管理者は、 eng を作成して、システム上の複数のユーザーが共有するディレクトリを設定できます。グループ、 engにユーザーを追加グループ化してから、 engを許可しますディレクトリrwxを持つグループ権限。これで、 engのすべてのユーザーディレクトリの読み取りと書き込みができます。

最近、ユーザーがシステム上のGPUデバイスへのアクセスを許可するのに苦労しているという問題が発生しました。

彼は次のようなコマンドを使用してデバイスを追加していました：

$ podman run --device /dev/video0 …

注：ルートレスコンテナでは、ルートレスユーザーは、デバイスをコンテナに追加するときに新しいデバイスを作成できません。したがって、Podmanは、デバイスをコンテナからホストにバインドマウントするだけです。ルートフルモードの場合、コンテナ内のプロセスがアクセスできる新しいデバイスが作成されます。

Podmanボリュームは/dev/video0にマウントされます、ただし、ユーザーがコンテナ内でデバイスを使用しようとするたびに、アクセスが拒否されましたで失敗します。。しかし、彼がホスト上のデバイスと彼がメンバーであるグループをチェックしたとき、すべてが正しく見えました。例：

$ ls -l /dev/video0 crw-rw----+ 1 root video 81, 0 May 3 14:06 /dev/video0 $ groups dwalsh video

彼はコンテナの外でデバイスを完全に使用できます。コンテナプロセスがビデオにないことに気付くグループで、彼はビデオを追加することを考えましたアクセスを取得するためにコンテナにグループ化します。彼はこのコマンドを試しました：

$ podman run --group-add video --device /dev/video0 …

しかし、それでも許可が拒否されましたで失敗しました。

どうしたの？

--group-add videoを使用する場合、動画を追加します次のように、コンテナイメージ内でコンテナのプライマリプロセスに定義されたグループ：

$ grep video /etc/group video: 39:

 $ podman run --group-add video fedora id uid=0(root) gid=0(root) groups=0(root),39(video) 

コンテナ内には、プロセスにグループ 39があります、しかしこれはではありません グループ39と同じホスト上。ルートレスコンテナを実行するときは、ユーザー名前空間を使用しているため、グループは参加しているユーザー名前空間によってオフセットされます。名前空間は次のとおりです：

$ podman unshare cat /proc/self/gid_map 0 3267 1 1 100000 65536 

これは、ビデオがコンテナ内のグループはGID100038になりますホスト上。この例を見てください：

$ ctr=$(podman run -d --group-add video fedora sleep 100) $ pid=$(podman top -l hpid | tail -1) $ grep Groups /proc/$pid/status Groups: 100038

ホスト上のビデオデバイスにアクセスするには、プロセスに実際の GID =39が必要です。、だから失敗します。ルートレスユーザーは、実際の GID =39へのアクセスを強制することはできません標準のLinux保護がホストをブロックするため、ホスト上で。

救助のポッドマン

Podman 3.2の時点で、新しい機能--group-add keep-groupsが追加されました。、OCIランタイムcrunで動作します。通常、Podmanコンテナを起動すると、OCIランタイムは setgroupsを実行します。システムコール;これにより、コンテナ内のメインプロセスが変更され、コンテナ内で定義されたグループが取得され、親プロセスグループへのアクセスも削除されます。通常、これは、コンテナからエスケープされたプロセスがホイールにアクセスすることを望まないため、発生させたいことです。たとえば、グループ。

--group-add keep-groupsを使用して実行する場合、OCIコンテナランタイム（crun ） setgroupsを呼び出さないしたがって、新しいコンテナプロセスは、その親プロセスのグループを維持します。親プロセスがGID=39にアクセスできる場合、コンテナ内のプロセスには引き続きそのグループがあり、デバイスを使用できます。

 $ podman run --device /dev/video0 --group-add keep-group …

そして、すべてが機能します！

[コンテナを使い始めますか？この無料コースをチェックしてください。コンテナ化されたアプリケーションのデプロイ：技術的な概要。 ]

補遺

コンテナ内では、GID 39 はマップされていないため、コンテナ内のプロセスはこれを誰もと見なしません。グループ。次のようになります：

$ ./bin/podman run --group-add keep-groups fedora groups root nobody

古いバージョンのPodmanには、crunでこの動作をトリガーするための使い勝手の悪いインターフェースがあります。 --annotation run.oci.keep_original_groups=1を追加する、crun setgroupsは実行されません。

$ podman run --annotation run.oci.keep_original_groups=1 --device /dev/video0

--group-add keep-groupsを使用する場合呼び出し、コンテナ内に他のグループを設定することはできません。代わりに、コンテナは親のグループのみを継承できます。この理由は、Podmanにはsetgroupsが必要なためです。を呼び出してコンテナ内に追加のグループを設定すると、親のグループにアクセスできなくなります。 Giuseppe Scrivanohasは、setgroupsを許可する2つのパッチを提案しました。この状況で。このアプローチはまだ議論中です。ジュゼッペはまた、ランタイム仕様に関する問題を開始しましたこれを仕様の正式な部分にし、runcなどの他のoci-runtimesに組み込むため、ただし、まだマージされていません。

まとめ

Podmanユーザーは、ユーザーがホスト上のこれらのリソースにアクセスできる場合でも、コンテナー内のファイルやデバイスにアクセスする際に問題が発生します。この問題が明らかになるユースケースを検討し、問題に対処するために提案されたパッチのいくつかについて説明しました。

[今すぐダウンロード：システム管理者によるBashスクリプトのガイド。 ]