Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Jan 21 '13 at 8:28

This question came from our site for professional and enthusiast programmers.

    
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

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer
    
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. –  user1783979 Jan 21 '13 at 15:53
    
"libnss_files*" rather. –  user1783979 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
....
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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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