Linux зависимости "id" и "whoami" (для среды chroot)

Question

У меня есть новая среда chroot openssh (openssh-server-6.1p1-4.fc18.i686) в Fedora Core 18 и помещает пользователей в структуру каталогов chroot с оболочкой (bash). Во время устранения неполадок SELinux находился в разрешительном режиме, чтобы исключить его как причину проблем.

При входе в систему пользователи видят следующее:

Using username "testuser".

Authenticating with public key "rsa-key-xxxxxxx" from agent
id: cannot find name for group ID 1002
id: cannot find name for user ID 1001
id: cannot find name for group ID 1002
id: cannot find name for user ID 1001
[I have no name!@fc18test ~]$

Whoami терпит неудачу подобным образом.

Каковы зависимости для правильной работы команды id в этой среде chroot? Раньше он прекрасно работал в предыдущей версии Fedora, использующей старые версии OpenSSH.

В среде chroot каталог /etc был воссоздан с помощью passwd & passwd-, group & group- и nsswitch.conf. В файле nsswitch.conf есть записи для "passwd" и "group", определенные как "файлы", и в соответствующих файлах есть и идентификатор пользователя, и идентификатор группы. Права доступа к файлам отражают права доступа к тем же файлам в стандартном каталоге /etc. Контексты SELinux также совпадают, хотя в этом нет необходимости, поскольку SELinux находится в разрешающем режиме при устранении неполадок.

Я думаю, что id вызывает либо getuid() либо geteuid() . Возможно ли, что мне не хватает библиотеки в каталоге chroot /lib ?

Может кто-нибудь пролить свет на то, что идет не так?

Answer 1

Спасибо за подсказку :)

Причиной этого является зависимость whoami от nss для поиска пользователей и групп.

Решение, которое я использовал, состояло в том, чтобы связать вызов whoami:

/ # strace /bin/whoami
....
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "/bin/whoami: cannot find name fo"..., 44/bin/whoami: cannot find name for user ID 0) = 44
close(1)                                = 0
close(2)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

которая была решена путем копирования отсутствующих файлов библиотеки.

Answer 2

Используйте ldd для проверки связанных библиотек, например:

 $ ldd $(which  whoami)
    linux-vdso.so.1 =>  (0x00007fff00bfe000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa25f48e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa25f871000)

Не беспокойтесь, если вы не можете найти linux-vdso в вашей системе, смотрите, например:

Библиотека, которую вы видите как linux-vdso.so.1, представляет собой виртуальную библиотеку или виртуальный динамический общий объект, который находится только в адресном пространстве каждой программы. Старые системы называли это linux-gate.so.1. Эта виртуальная библиотека обеспечивает необходимую логику, позволяющую пользовательским программам получать доступ к системным функциям с помощью самых быстрых средств, доступных на конкретном процессоре, либо с помощью прерывания, либо с большинством более новых процессоров, быстрым системным вызовом.