getpwuid() zwraca NULL dla użytkownika LDAP

Question

Mam problemy z pobieraniem aktualnych informacji o użytkowniku Red Hat Enterprise 6, w którym użytkownik jest użytkownikiem LDAP?

Mam pewien kod (w rzeczywistości część narzędzia instalacyjnego), który musi pobrać nazwę użytkownika, katalog domowy i inne szczegóły. Korzysta z wywołania getpwuid(), aby to zrobić na podstawie identyfikatora użytkownika. Uproszczony podział:

uid_t uid = getuid(); 
printf("UID = %d\n", uid); 

errno = 0; 
struct passwd* udetails = getpwuid(uid); 

if (udetails != NULL) 
{ 
    printf("User name = %s\n", udetails->pw_name); 
} 
else 
{ 
    printf("getpwuid returns NULL, errno=%d\n", errno); 
} 

Działa to bez problemów, gdy użytkownik jest użytkownikiem lokalnym (w tym systemie/etc/passwd).

Gdy użytkownik jest użytkownikiem uwierzytelnionym przez LDAP, wywołanie getuid zwraca identyfikator użytkownika lub bieżącego użytkownika, ale wywołanie getpwuid zwraca 0, bez kodu błędu ustawionego w errno. Zgodnie z dokumentacją oznacza to, że użytkownik nie istnieje.

Czy to działa? Zgodnie ze stroną getpwuid:

Funkcja getpwnam() zwraca wskaźnik do struktury zawierającej wyrenderowane pola rekordu w bazie danych haseł (np. Lokalny plik haseł/etc/passwd, NIS i LDAP), który pasuje do nazwy użytkownika.

Funkcja getpwuid() zwraca wskaźnik do struktury zawierającej uszkodzone pola rekordu w bazie danych haseł, które są zgodne z identyfikatorem użytkownika ID.

Czy wymagane jest połączenie alternatywne, aby uzyskać szczegółowe informacje, jeśli bieżący użytkownik został uwierzytelniony przez LDAP? Czy konieczne jest otwarcie bazy danych LDAP w aplikacji lub czy wywołanie systemowe powinno ją obsłużyć?

Dodatkowo: Próbowałem tego również na pudełku RHEL 5 uwierzytelniającym się w tym samym katalogu LDAP. Czy to może być problem z konfiguracją na pudełku RHEL 6? Lub szerszy problem RHEL 6? (Usunięte linie z komentarzem) /etc/nsswitch.conf wymagane przez Basile Starynkevitch::

dodatkowe

passwd:  files sss 
shadow:  files sss 
group:  files sss 

hosts:  files dns 

bootparams: nisplus [NOTFOUND=return] files 

ethers:  files 
netmasks: files 
networks: files 
protocols: files 
rpc:  files 
services: files sss 

netgroup: files sss 

publickey: nisplus 

automount: files ldap 
aliases: files nisplus 

Zgaduję, że niektóre z nich należy wspomnieć LDAP w pewnym momencie? W rzeczywistości sugeruje to, że wcale nie korzysta z protokołu LDAP ...

Answer 1

Problem wydaje się być nieobecny nss_sss bibliotek dla 32 bitów (w moim przypadku). Myślę, że dla RedHat jest to pakiet rpm: SSSD-client.i686.rpm

użyłem następujące makefile:

all: getpwuid_bug-32bit getpwuid_bug-64bit 

getpwuid_bug-32bit: getpwuid_bug.c makefile 
     $(CC) -Wall -m32 -o $@ $< 

getpwuid_bug-64bit: getpwuid_bug.c makefile 
     $(CC) -Wall -m64 -o $@ $< 

i następujący getpwuid_bug.c

#include <stdlib.h> 
#include <stdio.h> 
#include <errno.h> 
#include <sys/types.h> 
#include <unistd.h> 
#include <pwd.h> 

int main(argc, argv) 
    int argc; char **argv; 
{ 
    uid_t uid; 
    struct passwd *udetails; 

    uid = getuid(); 
    printf("UID = %d\n", uid); 

    errno = 0; 
    udetails = getpwuid(uid); 

    if (udetails != NULL) { 
    printf("User name = %s\n", udetails->pw_name); 
    } else { 
    printf("getpwuid returns NULL, errno=%d\n", errno); 
    return 1; 
    } 
    return 0; 
} 

Teraz Typ Marka ...

Następnie należy uruchomić zarówno

$ ./getpwuid_bug-32bit 
UID = 1234 
getpwuid returns NULL, errno=0 
$ ./getpwuid_bug-64bit 
UID = 1234 
User name = krico 
$ 

Następnie jeśli strace obie wersje programu, widać, że wersja 64 bit znajdzie nss_sss imediately

open("/lib64/libnss_sss.so.2", O_RDONLY) = 3 

gdzie jako jeden 32-bitowy nie zdało egzaminu po przejściu wielu z nich:

open("/lib/tls/i686/sse2/libnss_sss.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 
stat64("/lib/tls/i686/sse2", 0xfffef338) = -1 ENOENT (No such file or directory) 
open("/lib/tls/i686/libnss_sss.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 

Tak, mój wniosek jest taki, że trzeba zainstalować trochę rpm z tą 32-bitową wersją biblioteki (jak na przykład sssd-client.i686.rpm)

Answer 2

Mam podobny problem, próbowałem uruchomić Teamviewer9 na debian x64 (również wypróbowałem Ubuntu). Nie działało to dla kont w domenie Active Directory, Teamviewer się zawiesza, ponieważ getpwuid() zwraca null. Rozwiązałem instalację nscd, jak opisano w tej ubuntu bug.

Zajęło mi to dużo, aby to naprawić ...