Debian меняет владельца для Nobody:nogroup

Ваш контейнер работает как пользовательский (контейнер без root ), построенный на пользовательских пространствах имен .

Для работы пользовательские контейнеры имеют сопоставление uid / gid для преобразования хоста uid / gid в контейнер uid / gid . Общий диапазон хостов для них составляет 2 ^ 32 в ширину (, начиная с 0, являющегося реальным корневым пользователем ). Исходя из этого, выделенный диапазон для контейнера обычно сохраняется на уровне 2^16 (, что совместимо с историческими диапазонами uid ).

Любой хост uid , у которого нет преобразования диапазона в uid внутри контейнера, будет отображаться как none(соотв.:nogroup для gid) внутри пользовательского контейнера. Поскольку корень этого контейнера не имеет прав на такой uid , он не может изменить его, и операция завершится ошибкой, как при запуске обычным пользователем.

Вот ссылка из Proxmox с описанием вашей проблемы:

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

However you will soon realise that every file and directory will be mapped to "nobody" (uid 65534), which is fine as long as

• you do not have restricted permissions set (only group / user readable files, or accessed directories), and
• you do not want to write files using a specific uid/gid, since all files will be created using the high-mapped (100000+) uids.

Существуют инструменты, предназначенные для преобразования этих диапазонов, поэтому подготовленный макет системного дерева можно сместить в диапазон, подходящий для целевого контейнера. Этот инструмент должен запускаться с хоста (или, по крайней мере, в случае «рекурсивных» контейнеров, контейнер «породил» пространство имен пользователя ). Например:

https://github.com/jirutka/uidmapshift

который является повторной реализацией явно несуществующего uidmapshift проекта nsexec:

https://github.com/fcicq/nsexec

Конечно, вы можете сделать это вручную, рассчитав правильную цель uid:gid и используяchown(с хоста ). Если есть одно значение и простое сопоставление, это должно быть легко.Вот пример (с использованием запущенного пользовательского контейнера 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

Приведенная ниже команда получает процесс инициализации 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 

В случае, если файловая система контейнера (s )не смонтирована напрямую где-то в файловой системе хоста (, например :с использованием резервного хранилища 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 , которая все еще меняет форму , чтобы облегчить эти проблемы, выполняя это преобразование через связанное монтирование.