O Linux comanda as dependências “id” e “whoami” (para o ambiente chroot)

Question

Eu tenho um novo ambiente chroot openssh (openssh-server-6.1p1-4.fc18.i686) no Fedora Core 18 e coloca os usuários em uma estrutura de diretórios chroot com um shell (bash). Durante a solução de problemas, o SELinux está em modo permissivo para descartá-lo como a causa dos problemas.

Nos usuários de login, veja o seguinte:

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 falha de maneira semelhante.

Quais são as dependências para o comando id funcionar corretamente neste ambiente chroot? Ele costumava funcionar bem na versão anterior do Fedora, usando versões mais antigas do OpenSSH.

No ambiente chroot, o diretório / etc foi recriado com passwd & passwd-, group & group- e nsswitch.conf. O nsswitch.conf tem as entradas para "passwd" e "group" definidas como "files" e o ID do usuário e os ids do grupo existem nos arquivos apropriados. As permissões de arquivo espelham aquelas dos mesmos arquivos no diretório padrão / etc. Os contextos do SELinux também correspondem, embora não devam ser necessários, já que o SELinux está no modo permissivo durante a solução de problemas.

Acho que o id chama getuid() ou geteuid() . É possível que eu esteja faltando uma biblioteca no diretório chroot /lib ?

Alguém pode lançar alguma luz sobre o que está errado?

    

Answer 1

Use ldd para verificar bibliotecas vinculadas, por exemplo:

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

Não se preocupe se você não encontrar o linux-vdso em seu sistema, veja por exemplo :

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

Obrigado pela dica :)

A razão para isso é a whoami de dependência em nss para localizar usuários e grupos.

A solução que usei foi para avaliar a chamada 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 +++

que foi resolvido copiando os arquivos de biblioteca ausentes.