0 / 15 lessons — 0%
Lesson 02 / 15
Users, groups & sudo
Linux is multi-user at its core — even a single-person laptop has dozens of system accounts quietly running services. Understanding users and groups is what makes permissions from lesson 1 actually mean something.
# create a user, with a home directory sudo useradd -m -s /bin/bash alice sudo passwd alice # groups — collections of users sharing permissions sudo groupadd devs sudo usermod -aG devs alice # add alice to devs, keep her existing groups # who am I, what groups am I in whoami id alice groups alice
| File | Holds |
|---|---|
/etc/passwd | User accounts — username, UID, home dir, default shell (no passwords here anymore) |
/etc/shadow | Actual password hashes, readable only by root |
/etc/group | Group definitions and membership |
sudo lets a permitted user run commands as another user (usually root) without ever knowing root's actual password. Who's allowed to do what is defined in /etc/sudoers — always edit it with visudo, which validates syntax before saving so you can't lock yourself out with a typo.
# /etc/sudoers.d/devs — a scoped, safer alternative to editing sudoers directly %devs ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
Least privilege beats blanket sudo. Granting a team full, passwordless
ALL=(ALL) NOPASSWD: ALL is convenient right up until someone's laptop is compromised. Scope sudo rules to exactly the commands a role actually needs, like the example above.Try it yourselfRun
id with no arguments to see your own UID, GID, and every group you belong to. Then look at cat /etc/group | grep sudo (or wheel on RHEL-family systems) — that's the group actually granting sudo access.