web-dev-qa-db-ja.com

従属ユーザーIDを使用してファイルシステムのアクセス許可を付与できますか？

Uid/gid "1001"のユーザー "myuser"と、次の内容のファイル "/ etc/subuid"＆ "/ etc/subgid"があるとします。

myuser:100000:65536

この設定を使用して、ユーザー「myuser」が所有者「100000」のファイルにアクセスできるようにすることはできますか？

linuxusersnamespace
3
Thunderbeef

はい、setuid rootユーティリティ newuidmap および newgidmap を使用して /etc/subuid および /etc/subgid 。

podman、docker、またはLXCなどのツールでは、通常のユーザーでrootless /非特権モードで動作するようにこれらのsetuid rootユーティリティをインストールする必要があります。これらのツールがないと、bootstrap thisに使用できる十分な権限がありません。

長い説明はすべて user namespaces のマンページにあり、機能の使用方法を理解するために読む必要があります。簡単に言うと、（非特権操作で）ユーザー名前空間が作成されると、特定の疑似ファイル/proc/<PID>/{uid,gid}_mapを1回だけ書き込んで、マッピングを設定できます。次に、正しい（ホスト）特権を使用して、/etc/sub{uid,gid}で許可されているスペアのuid/gid範囲をユーザー名前空間にマップできます。

ユーザーmyuser自体（特別なコマンドの支援なしで）は、これらの疑似ファイルに書き込むことができますが、

  • 自分自身（Host uid 1001）をユーザー名前空間の1つのuidにマップすることのみが許可されています（明らかに有用な選択肢として、それ自体をもう一度、またはrootを0にすることができます）新規プロセスは一時的に新しく作成されたユーザー名前空間にマッピングされないため、これは他のプロセスからとにかく行う必要があります。マップされていないuidは、「解決」されるまでオーバーフローuid（デフォルトでは65534またはnobody）に変換されるため、独自の/proc/<PID>/uid_mapファイルに書き込むことができません。この名前空間でrootになったとしても、ホストuid 1001であるrootのみに影響を与える可能性があるため、これは役に立ちません。システムコール（およびそれらを使用するコマンド）はすべて、権限の昇格を許可しないように作成されています。 EPERMなどで失敗するだけでなく、マップされたuid（つまり、ホストuid 1001）をマップされていないuidに変更しようとすると、EINVALでも失敗する可能性があります。

  • グループでも同じですが、/proc/<PID>/gid_mapに書き込む前に setgroups を使用する機能を失う必要があるという追加の制限があります（これは、削除自分自身を削除できないようにするためです）グループから回避このグループの一部として追加されたファイルへの制限へ）。

したがって、uid 100000にはもちろん到達できません：setuid root tools are required。

ここでの目標は、通常のユーザーmyuserをuid 1001（従属IDに加えてnewuidmapによるマッピングで許可）をroot user（uid 0）としてマッピングすることです。 、およびまたユーザーネームスペース内の少なくともホストuid 100000をマップします。これにより、必要に応じて、（ユーザーネームスペースの）rootによって一方を他方に変更できます。ここでは、追加の100000を... 100000にマッピングします。 /etc/subgidが/etc/subuidのミラーであると仮定して、gidでも同じようにします。

以下は、newuidmapとnewgidmapを使用して、最初のホストユーザーmyuserから実行する方法の実用的な例です。上で説明したように、これには2つのプロセスが必要なので、ここでは2つのターミナルに2つのシェルがあります。これらのsetuid rootコマンドのアクションは、（Host）rootユーザーから実行される正しく細工されたecho（またはprintfなど）コマンドで置き換えることができます。

用語1：

$ unshare --user sh
$ id -u; id -un ; id -g; id -gn; echo pid:$$
65534
nobody
65534
nogroup
pid:13273

term2（コマンドで以前のpid値を再利用）：

$ newuidmap 13273 0 1001 1 100000 100000 1
$ newgidmap 13273 0 1001 1 100000 100000 1

再びterm1（シェルに「解決済み」および「アップグレード済み」のステータスを表示させるためのexec sh）：

$ id -u; id -un ; id -g; id -gn
0
root
0
root
$ exec sh
#

# touch mytest
# chown 100000:100000 mytest

term2（マッピングが同じ値で選択されたため、ここではterm1と同じように表示されます）：

$ ls -l mytest
-rw-r--r--. 1 100000 100000 0 Apr 21 18:00 mytest
$ touch mytest
touch: cannot touch 'mytest': Permission denied

用語1：

# chown 100001:100001 mytest
chown: changing ownership of 'mytest': Invalid argument
# chown root:root mytest

用語2：

$ ls -l mytest
-rw-r--r--. 1 myuser myuser 0 Apr 21 18:00 mytest

term1からのサブプロセスはすべて、ファイルシステム操作を含むuid 100000を制御するようになります。

/etc/subuidで許可されているように、より大きな範囲またはよりスマートなマッピングを使用して、より多くの事柄やより簡単に影響を与えることができます（例：100000をmyuserにマッピングする代わりに、newuidmap 13273 0 1001 1 1001 100000 1を使用すると、term1でsu myuserを実行するだけで済みます。いくつかの致命的でないエラーにもかかわらず、これは成功するはずです）。これにより、たとえば、関連のない問題が原因で起動を拒否するユーザーLXCインスタンスに（ネットワークなどの他の機能ではなく、ファイルシステムレベルでのみ）アクセス/レスキュー/バックアップすることもできます。

3
A.B