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?

  • Try running objdump -R /usr/bin/id or nm -D /usr/bin/id to find the symbols and back-trace it to the respective library, once you've found it, add that to the /lib within the chrooted environment... chances are you may have forgotten to copy the standard C library libc or similar...
    – t0mm13b
    Jan 21 '13 at 3:23

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.

  • Interestingly enough, the missing library files were not in the list ones returned from "ldd $(which id)" or "ldd $(which whoami)", but that information got me on the right path. I use a subset of the /lib (/usr/lib) directory in the chroot environment so to troubleshoot I copied the entire /lib directory to the chroot environment and then narrowed down which ones were missing by removing files. The missing lib files were "libnss_files*". I assume the culprits are dependencies of the library files returned by ldd(?).Thank you. Jan 21 '13 at 15:53
  • "libnss_files*" rather. Jan 21 '13 at 15:54

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
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.

  • You can also add the -e option to filter strace -e trace=open /bin/whoami
    – Christian
    May 2 '18 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.