After running `usermod -aG deploy alice` on a Linux host, Alice's already-open shell still cannot read the deploy group's files until she logs out and back in. Why, and what would happen if the `-a` had been omitted?

## Two kinds of membership A Linux account has exactly one **primary** group — the GID in field 4 of its `/etc/passwd` line — and any number of **supplementary** groups, which are the groups whose `/etc/group` line names it. The primary group is what newly created files are owned by; supplementary groups only ever grant access. That means `getent group deploy` and `id alice` can disagree. If `deploy` is Alice's primary group, her name will not appear in the group line at all, yet she is a member. `id` merges both sources, which is why it is the right tool to answer "is this user in that group?". ## Where the kernel actually keeps membership The kernel does not consult `/etc/group` when you open a file. Every process carries a credential set: real/effective/saved UID and GID, and a **supplementary group list**. A file access check compares those numbers against the file's owner and group. The text files are merely the *source* those numbers were loaded from, once, long ago. The loading happens in the privileged program that builds a session. `login`, `sshd` and `su` call `initgroups(3)`, which looks the user up through NSS and installs the resulting list with `setgroups(2)` — a call only a privileged process may make. Then it drops to the target UID and executes the shell. From that instant the list is frozen: `fork` copies it, `exec` preserves it, and nothing short of a new privileged session can widen it. ## Why the running shell is stale So `usermod -aG deploy alice` rewrites `/etc/group`, and every session started **afterwards** picks up the change. Alice's existing shell — and every editor, `tmux` pane and background job descended from it — still holds the credential set from her original login. It is not a cache that expires; it is state that was never designed to be updated. The clean demonstration: ``` $ id -nG alice # database lookup: shows deploy alice sudo deploy $ id -nG # this process's credentials: does not alice sudo ``` With no username argument `id` reports the calling process; with a username it queries the account database. Two different questions, two different answers, and the gap between them is the whole phenomenon. ## Getting the group without logging out - `newgrp deploy` starts a **new shell** whose credentials include the group (and makes it the primary group for files created in it). Members join without a password; non-members are challenged for the group password from `/etc/gshadow`, which is almost never set. - `sg deploy -c 'command'` runs one command under the new group set. - Reconnecting SSH, or `su - alice` from root, both create a fresh session and are the usual real-world answer. - Restarting the *service* is the equivalent step for daemons: a long-running process added to a group keeps the old set until it is restarted. ## The `-a` footgun `usermod -G` sets the supplementary list to exactly what you passed. Without `-a`: ``` usermod -G deploy alice # alice is now ONLY in deploy ``` She silently loses `sudo`, `adm`, `docker`, and anything else she had. This has locked administrators out of their own machines. `-a` (append) is only meaningful together with `-G`, and the habit worth building is to use the group-side tool instead: ``` gpasswd -a alice deploy # add gpasswd -d alice deploy # remove ``` `gpasswd` is additive by construction, so there is no destructive form to mistype. ## Practical consequences - **Automation**: a configuration-management run that adds a service account to a group must also restart the service, or the grant does nothing until the next reboot. - **Debugging access denials**: check the *process*, not the database. If a daemon gets EACCES, look at `/proc/<pid>/status` — the `Groups:` line is the credential set that process is actually using. - **Removal is worse than addition**: removing a user from a group does not revoke anything from sessions and processes already running under it. For a real revocation you must end those sessions. - **Directory-backed identity**: with LDAP or SSSD the group list is still installed at session creation, so caching in the directory client can add a second layer of staleness on top of this one.