Linux commands "id" and "whoami" dependencies (for chroot environment)

Question

I have a new openssh (openssh-server-6.1p1-4.fc18.i686) chroot environment in Fedora Core 18 and puts users in a chroot directory structure with a (bash) shell. During troubleshooting SELinux has been in permissive mode to rule it out as the cause of the problems.

On logon users see the following:

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 fails in similar fashion.

What are the dependencies for the id command to work properly in this chroot environment? It used to work fine in previous version of Fedora using older versions of OpenSSH.

In the chroot environment the /etc directory has been recreated with passwd & passwd-, group & group-, and nsswitch.conf. nsswitch.conf has the entries for "passwd" and "group" defined as "files" and both the user id and group ids exist in the appropriate files. File permissions mirror those of the same files in the standard /etc directory. The SELinux contexts match as well even though it shouldn't be necessary since SELinux is in permissive mode while troubleshooting.

I think id calls either getuid() or geteuid(). Is it possible that I'm missing a library in the chroot /lib directory?

Can anyone shed some light on what's going wrong?

Answer 1

Use ldd to check for linked libraries, e.g.:

 $ 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)

Don't worry if you can't find linux-vdso on your system, see e.g.:

The library that you see as linux-vdso.so.1 is a virtual library or Virtual Dynamic Shared Object, that resides only in each program's address space. Older systems called this linux-gate.so.1. This virtual library provides the necessary logic to allow user programs to access system functions through the fastest means available on the particular processor, either interrupt, or with most newer processors, fast system call.

Answer 2

Thanks for the hint :)

The reason for this is the whoami dependency on nss to find users and groups.

The solution I used was to strace the whoami call:

/ # 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 +++

which was solved by by copying the missing library files.