Subuid は、期待どおりに動作するようには設計されていません。これらは、ユーザーの名前空間内の UID をその名前空間外の別の UID にマップするように設計されており、コンテナーにとって便利です (そして実際に設計されました)。
ただし、プロセスが持つことができる UID セット (ユーザー名前空間) は 1 つだけであり、明らかなセキュリティ上の理由から、ユーザーはファイルの所有権を変更することはできません。プロセス自体に関する限り、ユーザーが実際に名前空間外の誰かであるかどうかは問題ではありません。
これが chown の理由です コマンドは失敗します:できるかどうかは問題ではありません 名前空間が異なっていたはず 、その時点ではその UID を持っていないため、ファイルの所有権を変更することはできません (root ではないため)。
ファイルを削除できる理由については、実際には subuid とは何の関係もありません。代わりに、ファイルが存在するディレクトリの所有権を持っているかどうかにすべて依存しています。ファイルを削除すると、ファイル自体ではなくディレクトリが変更されるため、ディレクトリに書き込むことも、そこからファイルを削除することもできます (「スティッキー」ディレクトリを除く)。
プログラム lxc-usernsexec があります lxc に付随するもの .これにより、マップ /etc/subuid を使用してユーザー ID を再マップできます。 と /etc/subgid .
具体的には、次のことができます。
<オール>lxc-usernsexec -- touch /tmp/test ls -l /tmp/test は、ファイルが所有者:グループであり、マップ内の最初の subuid:subgid ペアと同じであることを示します。rm /tmp/test 現在正しい uid/gid を持っていないため、エラーが発生するはずです。lxc-usernsexec -- rm /tmp/test ファイルを削除する必要があります。
お役に立てれば！上記は、非特権の LXC コンテナーを使用するためのさまざまなセットアップが必要になる可能性があります。特に /proc/sys/kernel/unprivileged_userns_clone だと思います 1 である必要があります。
あなたの問題は subuid とは何の関係もありません.
https://superuser.com/questions/697608/chown-operation-not-permittedによる
<ブロック引用>非特権ユーザー (root ではない) は、ファイルを他のユーザー名に chown できません。 chown を使用するには、ユーザーはターゲット ユーザーの権限を持っている必要があります。つまり、root だけが別のユーザーにファイルを渡すことができます。