web-dev-qa-db-ja.com

Debianがnobody：nogroupの所有者を変更

Nobody：nogroupを使用してディレクトリの所有権を変更するにはどうすればよいですか？私が試みたすべてが「許可されていない操作」に終わった。

cat /etc/debian_version
    10.2


root@torrent:/srv# chown -R rtorrent:rtorrent rtorrent 
chown: cannot read directory 'rtorrent/.local/share': Permission denied
chown: changing ownership of 'rtorrent/.local': Operation not permitted
chown: changing ownership of 'rtorrent/.bash_history': Operation not permitted
chown: changing ownership of 'rtorrent/session/rtorrent.dht_cache': Operation not permitted
chown: changing ownership of 'rtorrent/session': Operation not permitted
chown: changing ownership of 'rtorrent/.rtorrent.rc': Operation not permitted
chown: changing ownership of 'rtorrent/download': Operation not permitted
chown: changing ownership of 'rtorrent/watch': Operation not permitted
chown: changing ownership of 'rtorrent': Operation not permitted

rm -r download/
rm: cannot remove 'download/': Permission denied
root@torrent:/srv/rtorrent# ls -al
total 32
drwxr-xr-x 6 nobody nogroup 4096 Jan 24 18:16 .
drwxr-xr-x 3 root   root    4096 Jan 24 16:46 ..
-rw------- 1 nobody nogroup   47 Jan 24 18:16 .bash_history
drwxr-xr-x 3 nobody nogroup 4096 Jan 24 18:15 .local
-rw-r--r-- 1 nobody nogroup 3224 Jan 24 18:16 .rtorrent.rc
drwxr-xr-x 2 nobody nogroup 4096 Jan 24 16:46 download
drwxr-xr-x 2 nobody nogroup 4096 Jan 24 18:21 session
drwxr-xr-x 2 nobody nogroup 4096 Jan 24 16:46 watch
debianpermissions
3
toma3757

コンテナーは ser namespaces 上に構築されたユーザー（ルートレス）コンテナーとして実行されているようです。

機能するために、ユーザーコンテナにはuid/gidマッピングが関連付けられていますホストuid/gidをコンテナuid/gid。これらの全体的なホスト範囲は2 ^ 32幅です（0が実際のrootユーザーで始まる）。このことから、コンテナに割り当てられる範囲は通常2 ^ 16に保たれます（これは、履歴uid範囲と互換性があります）。

コンテナ内のuidに範囲変換されない任意のホストuidnobody（resp：nogroupforgid）ユーザーコンテナ内。このコンテナのrootはそのようなuidに対する権限を持っていないため、それを変更せず、通常のユーザーが実行したときのように操作が失敗します。

ここにあなたの問題を説明するProxmoxからのリンクがあります：

https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

ただし、すべてのファイルとディレクトリが「nobody」（uid 65534）にマッピングされることにすぐに気付くでしょう。

  • 制限されたアクセス許可セットを持っていない（グループ/ユーザーが読み取り可能なファイル、またはアクセスされたディレクトリのみ）、および
  • 特定のuid/gidを使用してファイルを書き込む必要はありません。すべてのファイルはハイマップ（100000+）uidを使用して作成されるためです。

これらの範囲を変換するための専用ツールがあるため、準備済みのシステムツリーレイアウトをターゲットコンテナーに適した範囲にシフトできます。これらのツールは、ホストから実行する必要があります（または、少なくとも「再帰的」コンテナーの場合、コンテナーはユーザー名前空間を「生成」します）。例えば：

https://github.com/jirutka/uidmapshift

これは明らかに機能しなくなったプロジェクトnsexecのuidmapshiftの再実装です。

https://github.com/fcicq/nsexec

もちろん、適切なターゲットuid：gidおよびchown（ホストから）を使用します。 1つの値と単純なマッピングがある場合、それは簡単です。次に例を示します（実行中のユーザーLXCコンテナーを使用）。

コンテナー（buster-AMD64と呼ばれます）：

user@buster-AMD64:~$ ls -n test
-rw-r--r--. 1 65534 65534 0 Jan 24 21:09 test

root@buster-AMD64:/home/user# chown user:user test
chown: changing ownership of 'test': Operation not permitted

ホスト（同じファイルを表示）：

user@Host:~$ ls -n ~/.local/share/lxc/buster-AMD64/rootfs/home/user/test
-rw-r--r--. 1 1000 1000 0 Jan 24 22:09 /home/user/.local/share/lxc/buster-AMD64/rootfs/home/user/test

以下のコマンドは、initプロセスを取得します 'pid（これはコンテナーでは1ですが、ここではpidホストで見られる値）コンテナーで実行中（コンテナーの他のプロセスも同様に機能します）：

user@Host:~$ lxc-info -Hpn buster-AMD64
22926
user@Host:~$ cat /proc/22926/uid_map 
         0    1410720      65536

このマッピングは、LXC構成で定義されている必要があります。

user@Host:~$ grep lxc.idmap ~/.local/share/lxc/buster-AMD64/config 
lxc.idmap = u 0 1410720 65536
lxc.idmap = g 0 1410720 65536

ユーザーコンテナのuidが1000で、ファイル/ディレクトリがこのユーザーに属している場合、新しいホストのuidは1410720 + 1000 = 1411720になります

ホストでは、今回は（実）rootユーザーとして：

root@Host:~# chown 1411720:1411720 ~user/.local/share/lxc/buster-AMD64/rootfs/home/user/test

コンテナーのファイルシステムがホストのファイルシステムのどこかに直接マウントされておらず（例：LVMバッキングストアまたはtmpfsマウントを使用して）到達できない場合、これは実行中のコンテナーでも機能します（とにかく推奨されるはずです）。

root@Host:~# chown 1411720:1411720 /proc/22926/root/home/user/test

そして今コンテナに：

user@buster-AMD64:~$ ls -n test
-rw-r--r--. 1 1000 1000 0 Jan 24 21:09 test

そして、そのrootユーザーは、正しいuid/gidマッピング。

root@buster-AMD64:~# chown root:root ~user/test
root@buster-AMD64:~#

カーネル側で進行中の作業があります shiftfs と呼ばれる機能があり、これはまだ フォームの変更 です=バインドマウントを介してこの変換を行うことにより、これらの問題を緩和するのに役立ちます。

3
A.B