Rootlessコンテナはホームサーバー上のUSBデバイスにアクセスできますか？

場合によります。コンテナを実行するユーザーは、あらかじめホスト側の権限を持っている必要があり、ランタイムはユーザー名前空間で利用できないケイパビリティを要求せずにデバイスをマッピングしなければなりません。

rootlessのメディア、ラジオ、UPS、または自動化コンテナが、取り外しや再起動後に消えて再び現れる可能性のある安定した /dev パスを必要とする場合、これは実際の互換性に関わる問題になります。まずは使い捨てのパスまたはアカウントから始め、以前の動作状態を利用できるようにしておき、一度だけの接続テストではなく、元のワークロードを基準に設計を評価してください。

Rootless USBデバイスアクセスの権限とIDの境界を設定する

サポートされる分岐は、ホストのグループまたはACLによるアクセスと、明示的にマッピングされたデバイスです。もう一方の分岐は、ホスト権限の不足、不安定なデバイスID、またはrootless分離によってブロックされた特権操作です。いずれかの分岐を変更する前に、バージョン、ID、アドレス、マウントパス、権限、現在観測できる状態を記録してください。

関連するrootlessユーザー名前空間が、最初の互換性の境界を定めます。これを使って主張の範囲を限定し、文書化された機能だけで完全な設計が動作すると判断せず、この正確なホームサーバーで同じ挙動を検証してください。

テスト前に判定ルールを記述します。成功とは、広範な特権モードを使わず、コンテナの再作成とホットプラグの後にプロセスが正しいデバイスを開けることです。失敗には、アクセス拒否、パスの変更、またはドライバー操作に依然としてホストレベルのケイパビリティが必要なことが含まれます。これにより、部分的な接続や正常なコマンド終了をエンドツーエンドの互換性と誤認するのを防げます。

特権を拡大せずにアクセスをテストする

1つの制御された判別方法を使います。安定したudev属性でデバイスを特定し、rootlessユーザーとしてホストアクセスを確認し、デバイスをマッピングしてから、使い捨てのデバイスを取り外して再接続します。変更されたコンポーネントだけが考えられる原因になるよう、クライアント、ワークロード、ファイルセット、アカウント、タイミングを一定に保ってください。

Podmanデバイスマッピングを使い、この経路で重要な2つ目の観測項目を選びます。トランザクションの両側を記録してください。リゾルバーまたはルート、ネゴシエートされたプロトコル、プロセスID、終了ステータス、レイテンシ、転送バイト数、復旧イベントです。

タイトルに示されたライフサイクルイベント（再作成、再接続、再マウント、再起動、フェイルオーバー、またはクライアント変更）の後にテストを繰り返します。古いソケット、キャッシュ、または認証情報が有効な間だけ動作する設計は、合格していません。

id
stat /dev/serial/by-id/*
podman run --device /dev/serial/by-id/DEVICE IMAGE

サポートされたアクセスと部分的な回避策を区別する

PASS: 広範な特権モードを使わず、コンテナの再作成とホットプラグの後にプロセスが正しいデバイスを開ける。これを生み出した正確なバージョンとトポロジーを保存してください。結論がプロトコルのすべての実装ではなく、その条件に適用されるためです。

FAIL: アクセスが拒否される、パスが変わる、またはドライバー操作に依然としてホストレベルのケイパビリティが必要になる。どちらの主要な分岐が原因かを宣言する前に、DNS、MTU、ID、ファイアウォールの状態、ストレージレイテンシ、キャッシュされたセッションなどの共有依存関係を確認してください。

EXCEPTION: デバイスマッピングを削除し、以前のACLまたはグループ状態を復元し、その操作をrootlessで実行できない場合に限り、範囲を限定したホストヘルパーを使用します。再現可能な観測によってどの境界が失敗したかを特定するまでは、特権を拡大したり、元データを削除したり、転送セキュリティを弱めたり、動作中のストレージを交換したりしないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

再接続または再起動後の永続性を確認する

観測された分岐に対応するアクションだけを適用し、その後、元のワークロードを再実行します。2回の関連するライフサイクルサイクルと想定される同時負荷の下で、広範な特権モードを使わず、コンテナの再作成とホットプラグの後にプロセスが正しいデバイスを開ける場合にのみ、設計を維持してください。

永続的なデバイスパススルーを使い、最も近い依存ワークフローを検証します。新しい設計が有効な間も、そのアクセス、タイミング、復旧動作は変わらない必要があります。

アクセスが拒否された場合、パスが変わった場合、またはドライバー操作に依然としてホストレベルのケイパビリティが必要な場合は、停止して保存した状態に戻してください。別の回避策を追加するのではなく、タイムスタンプ、正確なバージョン、ルートまたはマウントの証拠、最小限の再現手順を添えてエスカレーションしてください。

コンテナIDマッピングと結果を照合し、リスクが別のネットワーク、ID、バックアップ、またはストレージ層に移っただけにならないようにします。

したがって、rootless USBデバイスアクセスについての条件付きの答えは、冒頭の判断であり、無条件の「はい」ではありません。観測可能な合格状態が受け入れの基準線であり、失敗状態がロールバックの基準線です。

FAQ

ユーザーをdialoutに追加すれば、すべてのUSBケースが解決しますか？

いいえ。そのノードがそのグループを使用し、追加の特権ioctlが必要ない場合に限り、シリアルデバイスで役立ちます。

rootlessコンテナはホットプラグを自動的に検出できますか？

マッピングされたパスとランタイムの動作がデバイスイベント後も維持される場合に限ります。取り外しと再接続のサイクルをテストしてください。

代わりにコンテナをprivilegedで実行すべきですか？

最初からそうするべきではありません。まず、正確に拒否された操作を特定し、それを満たす最小限のホスト側権限を付与してください。