Linux: groups vs. groups username

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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$