私の「一般」システムとは別のマウントとユーザーの名前空間にtmpfsをインストールするときに、すべてのユーザー/グループIDを使用できると予想されます。
tmpfsはそのマウントネームスペースにのみ存在するため、マッピングIDは必要ありません(ただし、/ etc / sub { g、u} idを設定しました)。
しかし、起こっていることは次のとおりです。
me $ mkdir tmp
me $ unshare -Urm
root $ mount -t tmpfs none tmp
root $ cd tmp
root $ touch asdf
root $ chown 3:3 asdf
chown: changing ownership of 'asdf': Invalid argument
理由は不明です。誰かがこれについて明らかにできますか?
コピー - 貼り付けテストの場合unshare -Urm
:
mkdir tmp
mount -t tmpfs none tmp
cd tmp
touch asdf
chown 3:3 asdf
答え1
特定のユーザー名前空間の場合、名前空間内にマップされていない特定のUIDまたはGIDを持つすべてのプロセス(実行中の実際の初期ルートユーザーにも影響を与える可能性があります)unshare -Urnm
は、システムコールに応じてEPERMまたはEINVALエラーを受け取ります。 :何らかの方法でそのUIDに影響を与える操作(プロセスやファイルなど)を実行しようとしています。で説明されていますが、user_namespace(7)
説明はかなり複雑です。
対応するUID / GID値を読み取ろうとします。 EINVALが発生しない場合、オーバーフローしたUID / GIDが検索されます。通常、誰もグループを検索しません。詳しくはこちらをご覧ください。マップされていないユーザーとグループIDuser_namespace(7)
マンページから。
複数のUIDを含める唯一の方法は、特権ヘルパーを使用することです。podman
.command など、一般ユーザーとして実行するように設計されたツールにも依存する共通のヘルパーがあります。newuidmap
そしてnewgidmap
ユーザー資格情報の確認/etc/subuid
そして/etc/subgid
。これらのファイルのエントリは通常、ユーザーアカウントの作成時に追加されますが、追加の要件を満たすように変更できます。
ユーザーがユーザーの名前空間をルートに一方的に変更し、親(ホストなど)ユーザーの名前空間に影響を与える可能性がある場合、そのユーザーはrootユーザーの権限を持ちます。しかし、実際にはそうではありません。ヘルパーの使用の目的の目的は、このユーザーのUID-GID範囲(0-65534だけでなく0-4294967294の下位範囲)を予約することです。責任のために、マッピングはユーザーごとに異なります(ただし必須ではありません)。