Does anybody know why the linux command
groups
shows a different output than
groups username
The logged in user is the same as the parameter username. Example:
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
When you run groups username, it looks up1 the given user in /etc/passwd and /etc/group (although it can be LDAP, NIS or something else2) and shows you all groups found.
On the other hand, when you run the groups command without any arguments, it simply lists all groups it itself belongs to3 – which is not necessarily the same as what is listed in /etc/group. (See below for an explanation.) In fact, the only lookups made to /etc/group are for translating GIDs to group names.
Each process has a set of credentials, which contains (among other things) a "real group ID" (primary GID), an "effective group ID" (EGID), and a list of "supplementary group" IDs (secondary GIDs). By default, a process inherits its credentials from its parent; however, processes running as root (UID 0) or having the CAP_SETUID capability are allowed to set arbitrary credentials.
In particular, when you log in to Linux (whether in a tty, X11, or over SSH), the login process (/bin/login, gdm, sshd) looks up your username to determine your UID, primary GID, and secondary GIDs. On a personal machine, this just means reading the appropriate lines from passwd and group files (or NIS, LDAP, etc).
Next, the login process switches4 to those credentials before starting your session, and every process you launch from now on will have the exact same UID & GIDs – the system does not check /etc/group anymore5 and will not pick up any modifications made.
In this way, the /usr/bin/groups process will belong to the same groups as you did when you logged in, not what the database says you are in.
Note: The above explanation also applies to almost all Unixes; to the Windows NT family (except UIDs and GIDs are all called "SIDs", there is no "primary group", the credentials are called the "process token", and CAP_SETUID is SeCreateTokenPrivilege or SeTcbPrivilege); and likely to most other multi-user operating systems.
1 getpwuid() and getgrouplist() are used to look up a user's groups.
2 On Linux, glibc uses /etc/nsswitch.conf to determine where to look for this information.
3 groups uses getgid(), getegid() and getgroups() to obtain its own credentials.
4 setuid(), setgid(), initgroups() and related.
5 An exception, of course, is the various tools that run elevated (setuid) such as su, sudo, sg, newgrp, pkexec, and so on. This means that su $USER will spawn a shell with the updated group list.
groups on its own gives the current group membership of the owner of the process. This can differ from groups <username> if the groupdb has changed since the process started or the process owner changed.
groups doesn't give current membership, but rather that which was "current" at the time when the login process (/sbin/login, gdm, sshd) called initgroups().
– u1686_grawity
Apr 24 '12 at 21:03
Just restart the computer and both groups and groups user should give the same results.
The reason they were different was because you added yourself to a new group which you weren't a member of when you started the computer.
su, closing a reopening the current session). You can also use newgrp to start processes with the new group included.
– pabouk - Ukraine stay strong
Nov 18 '13 at 10:04
Run updatedb, see if there is any change.
The same in my OSX machine when groupdb has not changed:
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$
