Linux: groups vs. groups username

When you run groups username, it looks up¹ the given user in /etc/passwd and /etc/group (although it can be LDAP, NIS or something else²) 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 to³ – 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 switches⁴ 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 anymore⁵ 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.

¹ getpwuid() and getgrouplist() are used to look up a user's groups.

² On Linux, glibc uses /etc/nsswitch.conf to determine where to look for this information.

³ groups uses getgid(), getegid() and getgroups() to obtain its own credentials.

⁴ setuid(), setgid(), initgroups() and related.

⁵ 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.

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.

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$