基本的に、ここで何が起こっているのですか?
ユーザーに一連のsubuidがあります。このユーザーの割り当ての一部である特定のサブIDにファイルを変更したい
administrator@Host:/home/administrator$ cat /etc/subuid
root:100000:65536
administrator:165536:65536
administrator:1000000:9000001
administrator@Host:/home/administrator$ cat /etc/subgid
root:100000:65536
administrator:165536:65536
administrator:1000000:9000001
このsubuidが割り当ての一部であるにもかかわらず、このファイルをchownしようとすると失敗します。
administrator@Host:/home/administrator$ ls -lhat
...
-rw-rw-r-- 1 administrator administrator 229 Aug 2 13:00 file
drwxrwxr-x 7 administrator administrator 4.0K Aug 2 13:00 ..
administrator@Host:/home/administrator$ chown 1500000:1500000 file
chown: changing ownership of 'file': Operation not permitted
administrator@Host:/home/administrator$ stat file
File: file
Size: 229 Blocks: 8 IO Block: 4096 regular file
Device: 802h/2050d Inode: 658357 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/administrator) Gid: ( 1004/administrator)
Access: 2018-08-02 13:00:36.529197108 +0000
Modify: 2018-08-02 13:00:36.529197108 +0000
Change: 2018-08-02 13:00:36.529197108 +0000
Birth: -
administrator@Host:/home/administrator$
ただし、Sudoを使用してファイルを変更すると、ユーザーとしてファイルを削除できますが、実行すると書き込み禁止ファイルとして表示されます。これは、私が実際にこのsubuidでファイルを変更する権限を持っていることを示しています。
administrator@Host:~$ touch file
administrator@Host:~$ chown 1500000:1500000 file
chown: changing ownership of 'file': Operation not permitted
administrator@Host:~$ Sudo chown 1500000:1500000 file
administrator@Host:~$ rm file
rm: remove write-protected regular empty file 'testfile.txt'?
administrator@Host:~$
ここで起こっている内部の仕組みを誰かが説明できますか?おそらくどこかで基本的なことを誤解しているでしょう。担当者が不足しているため、これにsubuidのタグを付けることができないため、uidを使用します。
ありがとう!
プログラムがありますlxc-usernsexec
はlxc
に付属しています。これにより、マップを使用してユーザーIDを再マップできます/etc/subuid
および/etc/subgid
。
具体的には、次のことができます。
lxc-usernsexec -- touch /tmp/test
ls -l /tmp/test
は、ファイルがマップの最初のsubuid:subgidペアと同じowner:groupであることを示します。rm /tmp/test
は、現在正しいuid/gidを持っていないため、エラーになります。lxc-usernsexec -- rm /tmp/test
はファイルを削除する必要があります。お役に立てれば!上記はおそらくLXCコンテナーの非特権使用のためにさまざまな設定が必要です。特に/proc/sys/kernel/unprivileged_userns_clone
は1でなければなりません。
Subuidは、期待どおりに動作するようには設計されていません。これらは、ユーザー名前空間のUIDをその名前空間外のさまざまなUIDにマップするように設計されています。これは、コンテナーに役立ちます(実際に設計されました)。
ただし、プロセスは依然として1つのUIDセット(ユーザー名前空間)しか持つことができず、ユーザーは明らかなセキュリティ上の理由から、ファイルの所有権を変更することはできません。プロセス自体に関する限り、ユーザーが実際にネームスペース外の誰かであるかどうかは問題ではありません。
これがchown
コマンドが失敗する理由です。couldが他のUIDを持っているかどうかは問題ではありません名前空間が異なる場合、その瞬間、そのUIDを持っていないので、(rootでないため)ファイルの所有権を変更することはできません。
なぜファイルを削除できるのか:それは実際にはsubuidとは何の関係もありませんが、代わりに、ファイルが存在するディレクトリの所有権を持っているかどうかに依存します。ファイルを削除すると、ファイル自体ではなくディレクトリが変更されますディレクトリを書き込んだり、そこからファイルを削除したりできます(「スティッキー」ディレクトリを除く)。
あなたの問題はsubuidとは何の関係もありません。
によると https://superuser.com/questions/697608/chown-operation-not-permitted
非rootユーザー(root以外)は、ファイルを他のユーザー名に変更できません。 chownを使用するには、ユーザーはターゲットユーザーの権限を持っている必要があります。つまり、rootだけが別のユーザーにファイルを渡すことができます。