Users and groups
Linux is a multi-user system. Every file and process belongs to a user and group, and the kernel uses those identities to decide what each may do.
User accounts
Each user has a name and a numeric user ID (UID). The kernel works with numbers; names are for people. Root, UID 0, is the superuser with full control. System accounts with low UIDs (typically below 1000) run services such as web servers and databases, while regular users usually start at UID 1000. id shows your UID, primary group, and other groups.
Account files
/etc/passwd lists accounts, one per line with fields separated by colons: name, a placeholder x for the password, UID, GID, a comment such as the full name, home directory, and login shell, for example ana:x:1001:1001:Ana Ruiz:/home/ana:/bin/bash. Password hashes are kept in /etc/shadow, readable only by root, along with password-ageing information.
Groups
Groups let permissions be granted to sets of users. Each user has a primary group, recorded in /etc/passwd, and can belong to supplementary groups listed in /etc/group. On many distributions each user gets a private group of the same name. Groups such as sudo or wheel (administrators), docker, and audio grant particular abilities.
Managing accounts
useradd (or the friendlier adduser on Debian-based systems) creates accounts; usermod changes them, such as usermod -aG developers ana to add Ana to a group (-a appends, which matters); userdel removes them; passwd sets passwords; groupadd creates groups. Group changes take effect at the next login. chage manages password expiry.
Password storage
Linux never stores passwords themselves. /etc/shadow holds salted hashes produced by slow algorithms such as yescrypt (the default on recent Debian, Ubuntu, and Fedora) or SHA-512 crypt. A random salt per user means identical passwords produce different hashes, and slow hashing makes guessing attacks expensive if the file is ever stolen.
Authentication with PAM
Pluggable Authentication Modules (PAM) let administrators configure how programs such as login, ssh, and sudo authenticate users, through stacks of modules in /etc/pam.d/. Modules can check local passwords, query directory services such as LDAP or Active Directory, enforce password strength, lock accounts after failures, or require one-time codes for multi-factor authentication.
sudo and least privilege
Logging in as root directly is discouraged. sudo lets authorised users run individual commands as root, or as another user, after confirming their own password, with each use logged. The /etc/sudoers file, edited safely with visudo, defines who may run what; members of sudo or wheel commonly have full access. su switches to another account entirely, typically root.
Worked example
To give a new developer access: sudo adduser ben creates the account and home directory; sudo usermod -aG developers,docker ben adds Ben to two groups without removing existing ones; Ben logs out and in again; id ben now lists both groups. Omitting -a and running usermod -G docker ben would replace Ben's supplementary groups with docker alone, silently removing developers.
Key takeaways
Users have names and numeric UIDs; root is UID 0; system accounts use low UIDs and regular users often start at 1000. /etc/passwd holds account fields; /etc/shadow holds salted, slow hashes such as yescrypt or SHA-512, readable only by root. Groups, recorded in /etc/group, grant shared access; users have primary and supplementary groups. useradd, usermod -aG, userdel, passwd, and groupadd manage accounts, and group changes apply at next login. PAM configures authentication, including LDAP and multi-factor options. sudo, configured with visudo, grants logged, limited root access in line with least privilege.
Flashcard
Numeric user ID
Check your understanding
Why does usermod -G docker ben differ dangerously from usermod -aG docker ben?