Linux: nazwa użytkownika grupy kontra grupy

Czy ktoś wie, dlaczego polecenie linux

    groups 

pokazuje inne wyjście niż

    groups username 

Zalogowany użytkownik jest taki sam jak parametr nazwa użytkownika. Przykład:

    thorsten@ubuntu:~/tmp$ groups
    thorsten adm dialout cdrom plugdev lpadmin admin sambashare
    thorsten@ubuntu:~/tmp$ groups thorsten
    thorsten : thorsten adm dialout cdrom plugdev nogroup lpadmin admin sambashare

Po uruchomieniu wyszukuje ¹ danego użytkownika i (chociaż może to być LDAP, NIS lub coś innego ² ) i pokazuje wszystkie znalezione grupy.groups username/etc/passwd/etc/group

Z drugiej strony, po uruchomieniu groupspolecenia bez żadnych argumentów, po prostu wyświetla listę wszystkich grup, do których on sam należy, do ³ - co niekoniecznie jest takie samo jak to, co jest wymienione /etc/group. (Objaśnienia znajdują się poniżej). W rzeczywistości jedynymi dokonanymi przeglądami /etc/groupsą tłumaczenia GID na nazwy grup.

Każdy proces ma zestaw poświadczeń , który zawiera (między innymi) „rzeczywisty identyfikator grupy” (podstawowy GID), „efektywny identyfikator grupy” (EGID) oraz listę „dodatkowych grupowych” identyfikatorów (wtórne GID). Domyślnie proces dziedziczy dane uwierzytelniające po rodzicu; jednak procesy działające jako root (UID 0) lub posiadające taką CAP_SETUIDmożliwość mogą ustawić dowolne poświadczenia.

W szczególności, gdy logujesz się do systemu Linux (czy to w tty, X11, czy przez SSH), proces logowania (/ bin / login, gdm, sshd) wyszukuje twoją nazwę użytkownika w celu ustalenia twojego UID, podstawowego GID i pomocniczego GID . Na komputerze osobistym oznacza to po prostu odczyt odpowiednich wierszy passwdi groupplików (lub NIS, LDAP itp.).

Następnie proces logowania przełącza ⁴ na te dane uwierzytelniające przed rozpoczęciem sesji, a każdy proces, który uruchomisz odtąd, będzie miał dokładnie takie same UID i GID - system nie sprawdza /etc/groupjuż ⁵ i nie wykrywa żadnych dokonanych modyfikacji.

W ten sposób /usr/bin/groupsproces będzie należeć do tych samych grup, co podczas logowania , a nie do tego, co mówi baza danych.

Uwaga: powyższe wyjaśnienie dotyczy także prawie wszystkich uniksów; do rodziny Windows NT (oprócz UID i GID wszystkie nazywane są „SID”, nie ma „grupy podstawowej”, poświadczenia nazywane są „tokenem procesu” i CAP_SETUIDsą to SeCreateTokenPrivilege lub SeTcbPrivilege ); i prawdopodobnie dla większości innych systemów operacyjnych dla wielu użytkowników.

¹ getpwuid () i getgrouplist () służą do wyszukiwania grup użytkowników.

² W systemie Linux glibc używa /etc/nsswitch.confdo określenia, gdzie szukać tych informacji.

³ groups używa getgid (), getegid () i getgroups () w celu uzyskania własnych poświadczeń.

⁴ setuid (), setgid (), initgroups () i powiązane.

⁵ wyjątkiem, oczywiście, różne narzędzia, które działają zwiększone ( setuid ), takie jak su, sudo, sg, newgrp, pkexec, i tak dalej. Oznacza to, że su $USERspawnuje powłokę ze zaktualizowaną listą grup.

groupssamodzielnie daje bieżące członkostwo grupy właścicielowi procesu. Może się to różnić od sytuacji, groups <username>gdy groupdb zmieniło się od czasu rozpoczęcia procesu lub zmienił się właściciel procesu.

Po prostu uruchom ponownie komputer, a zarówno grupy, jak i grupy użytkowników powinny dać takie same wyniki.

Różniły się one dlatego, że dodałeś się do nowej grupy, do której nie należałeś, kiedy uruchamiałeś komputer.

Uruchom updatedb, sprawdź, czy jest jakaś zmiana.

To samo na moim komputerze z systemem OSX, gdy groupdb się nie zmieniło:

albert-hotspot:~ sami$ groups sami
staff com.apple.access_screensharing com.apple.sharepoint.group.2 everyone _appstore localaccounts _appserverusr admin _appserveradm _lpadmin _lpoperator _developer
albert-hotspot:~ sami$ groups
staff com.apple.access_screensharing com.apple.sharepoint.group.2 everyone _appstore localaccounts _appserverusr admin _appserveradm _lpadmin _lpoperator _developer
albert-hotspot:~ sami$