В systemd определен nobody как имеющий UID равный 65534, см. https://github.com/systemd/systemd/blob/master/src/basic/user-util.h#L59 В альт оный имеет UID 99. Это выливается в визуально несимпатичный вывод `ls` в контейнерах с включенными user namespaces. Выливается ли это несоответствие во что-то ещё, мне лично неизвестно. По всей видимости, проблемы будут у тех, кто подготавливает контейнеры для использования в systemd (сомнительно что таких пользователей сильно больше нуля). Хотя поиск по исходникам выдаёт и более подозрительные модули. Подозреваю что простая замена числа в указанном заголовочном файле на 99 может как раз таки привести к проблемам, так как во многих местах systemd предполагает что в адекватных системах нет UID больше чем UID_NOBODY.
Покажите несимпатичный вывод ls. Как воспроизвести? Какой дистрибутив внутри контейнера?
(Ответ для Alexey Shabalin на комментарий #1) > Покажите несимпатичный вывод ls. > Как воспроизвести? > Какой дистрибутив внутри контейнера? чтобы воспроизвести: # machinectl import-tar alt-p9-rootfs-systemd-x86_64.tar.xz t1 # machinectl start t1 # machinectl shell t1 # Connected to machine t1. Press ^] three times within 1s to exit session. [root@t1 ~]# ls -la / total 72 ... drwxr-xr-x 2 root root 4096 Sep 4 15:37 opt dr-xr-xr-x 297 65534 65534 0 Jan 16 00:11 proc drwx------ 4 root root 4096 Nov 3 05:17 root ... [root@t1 ~]# Дистрибутив виден по имени импортируемого файла, от него не зависит. Эти 65534 то, как systemd устанавливает владельца внешних файлов. Например, такой владелец будет у файлов подмонтированных через опции bind этого nspawn.
Даже если поправить в src/basic/user-util.h, то в src/basic/user-util.c /* We enforce some special rules for uid=0 and uid=65534: in order to avoid NSS lookups for root we hardcode * their user record data. */ ... STR_IN_SET(*username, NOBODY_USER_NAME, "65534")) ... Я бы пока смирился с некрасивым выводом, не понятно как изменение на 99 может отразится, например на контейнерах других дистрибутивов (fedora, debian).
