Linux: nom d'utilisateur des groupes et des groupes

12

Est-ce que quelqu'un sait pourquoi la commande linux 

    groups

affiche une sortie différente de

    groups username

L'utilisateur connecté est le même que le nom d'utilisateur du paramètre. Exemple:

    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
linux user-accounts Thorsten Niehues
la source
1
Il y a tellement de doublons de cette question que je ne sais même pas par où commencer.
user1686

Réponses:

12

Lorsque vous exécutez , il recherche 1 l'utilisateur donné dans ( et bien qu'il puisse être LDAP, NIS ou autre chose 2 ) et vous montre tous les groupes trouvés.groups username/etc/passwd/etc/group

D'autre part, lorsque vous exécutez la groupscommande sans aucun argument, il énumère simplement tous les groupes , il s'appartient à 3 - qui est pas nécessairement la même chose que ce qui est indiqué dans /etc/group. (Voir ci-dessous pour une explication.) En fait, les seules recherches effectuées pour /etc/groupsont pour traduire les GID en noms de groupe.

Chaque processus possède un ensemble d' informations d' identification , qui contient (entre autres) un "ID de groupe réel" (GID principal), un "ID de groupe effectif" (EGID) et une liste d'ID de "groupe supplémentaire" (GID secondaires). Par défaut, un processus hérite ses informations d'identification de son parent; cependant, les processus s'exécutant en tant que root (UID 0) ou ayant la CAP_SETUIDcapacité sont autorisés à définir des informations d'identification arbitraires.

En particulier, lorsque vous vous connectez à Linux (que ce soit dans un tty, X11 ou via SSH), le processus de connexion (/ bin / login, gdm, sshd) recherche votre nom d'utilisateur pour déterminer votre UID, GID principal et GID secondaires . Sur une machine personnelle, cela signifie simplement lire les lignes passwdet les groupfichiers appropriés (ou NIS, LDAP, etc.).

Ensuite, le processus de connexion bascule 4 sur ces informations d'identification avant de démarrer votre session, et chaque processus que vous lancez aura désormais exactement les mêmes UID et GID - le système ne vérifie /etc/groupplus 5 et n'acceptera aucune modification apportée.

De cette façon, le /usr/bin/groupsprocessus appartiendra aux mêmes groupes que vous l'avez fait lorsque vous vous êtes connecté , et non à ce que la base de données indique que vous êtes.

Remarque: L'explication ci-dessus s'applique également à presque tous les Unix; à la famille Windows NT (sauf que les UID et GID sont tous appelés "SID", il n'y a pas de "groupe principal", les informations d'identification sont appelées "jeton de processus" et CAP_SETUIDsont SeCreateTokenPrivilege ou SeTcbPrivilege ); et probablement à la plupart des autres systèmes d'exploitation multi-utilisateurs.

1 getpwuid () et getgrouplist () sont utilisés pour rechercher les groupes d'un utilisateur.

2 Sous Linux, glibc utilise /etc/nsswitch.confpour déterminer où chercher ces informations.

3 groups utilise getgid (), getegid () et getgroups () pour obtenir ses propres informations d'identification.

4 setuid (), setgid (), initgroups () et connexes.

5 exception An, bien entendu, les différents outils qui exécutent élevée ( setuid ) tels que su, sudo, sg, newgrp, pkexec, et ainsi de suite. Cela signifie que su $USERva générer un shell avec la liste des groupes mise à jour.

user1686
la source
3

groupsdonne à lui seul l' appartenance au groupe actuel du propriétaire du processus. Cela peut différer groups <username>si la groupdb a changé depuis le démarrage du processus ou si le propriétaire du processus a changé.

Ignacio Vazquez-Abrams
la source
groupsne donne pas l' appartenance actuelle , mais plutôt celle qui était "actuelle" au moment où le processus de connexion (/ sbin / login, gdm, sshd) a appelé initgroups().
user1686
1

Redémarrez simplement l'ordinateur et l'utilisateur des groupes et des groupes devrait donner les mêmes résultats.

La raison pour laquelle ils étaient différents est que vous vous êtes ajouté à un nouveau groupe dont vous n'étiez pas membre lorsque vous avez démarré l'ordinateur.

Alex
la source
Vous n'avez certainement pas besoin de redémarrer l'ensemble du système! Il vous suffit de démarrer une nouvelle session de connexion (c'est-à-dire sur une nouvelle console virtuelle, en utilisant su, en fermant et en rouvrant la session en cours). Vous pouvez également utiliser newgrppour démarrer des processus avec le nouveau groupe inclus.
pabouk
1
Je voulais seulement donner une solution simple et rapide qui fonctionnera à chaque fois. Il existe de nombreuses autres réponses qui répondent déjà en détail à cette question. Parfois, ce que les gens veulent, comme dans mon cas, est une solution simple qui fonctionne sans passer par plusieurs étapes.
Alex
0

Exécutez updatedb, voyez s'il y a un changement.

La même chose sur ma machine OSX lorsque groupdb n'a pas changé:

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$
Léo Léopold Hertz 준영
la source