Remove someone from sudo by accident, then fix it

short · 20 min · Objective 2.2

Before you start — what this lab needs

A disposable container or virtual machine. You will be modifying accounts and group membership, so do not do this on a machine you care about:

podman run -it --name lab-users --rm rockylinux:9 bash

Task

Reproduce the single most damaging one-character omission in Linux account management -- usermod -G instead of usermod -aG -- observe exactly what it destroys, and repair it. Then prove to yourself that locking an account does not stop key-based login.

Steps

Create a user and put them in two supplementary groups: useradd -m alice, groupadd developers, usermod -aG wheel,developers alice.
Record the starting position with id alice. Write the group list down -- you will need it to prove the repair.
Now make the mistake: usermod -G developers alice.
Run id alice again and compare. Note that wheel has gone, and that nothing warned you.
Repair it with the append form, and confirm the list matches step 2.
Set a password for alice, then lock the account with passwd -l alice and read the effect directly: grep alice /etc/shadow shows the hash prefixed with an exclamation mark.
Confirm the distinction: passwd -S alice reports L for locked. Then expire the account instead with chage -E 1970-01-02 alice and read chage -l alice.

Verify

id -nG alice                         # must list wheel AND developers again
passwd -S alice | awk '{print $2}'   # L while locked, P once unlocked
chage -l alice | grep -i 'account expires'
grep '^alice:' /etc/shadow | cut -d: -f2 | cut -c1

After step 5, id -nG alice must contain both groups. The fourth command prints ! while the account is locked -- that single character is the entire locking mechanism, and seeing it makes the SSH-key gap obvious.

Notes

The reason the missing -a is so damaging is that it fails silently and successfully. There is no prompt, no warning and a zero exit status. The only protection is the habit: run id before and after, every time.