sudo = POWER!! (managing users in Linux) // Linux for Hackers // EP4
Based on NetworkChuck's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
User accounts are listed in `/etc/passwd`, while password hashes are stored in `/etc/shadow` and require `sudo` to view.
Briefing
User management is the foundation for both legitimate Linux administration and practical hacking: it determines who can log in, what they can access, and how far they can go when permissions escalate. The lesson starts by identifying the current account with `whoami`, then shows how Linux stores account data in `/etc/passwd` and password hashes in `/etc/shadow`. A user account entry includes a username, a UID/GID pair, a home directory path, and a default login shell—often `bash` when created with `adduser`.
From there, the core workflow becomes creating, inspecting, and removing accounts—using the “Avengers” as a memory hook. Creating users can be done two ways: `adduser` and `useradd`. `adduser` is interactive and “does more” by prompting for details like passwords and typically setting up a home directory and other defaults. `useradd` is more barebones: it can create the account record, but it may leave out essentials such as a home directory and can result in a different default shell (the transcript shows `sh` instead of `bash`). After creating a user with `useradd`, the password can be set or changed using `passwd`, and the shell can be corrected with `usermod --shell /bin/bash`.
The next escalation step is privilege management—where the “Infinity Gauntlet” metaphor maps directly to `sudo`. `sudo` grants temporary superuser capabilities (root powers) for a single command, which is why it’s safer than logging in as root. The transcript demonstrates switching identities with `su` (requiring the target user’s password) and contrasts that with `sudo` (which relies on authorization rules rather than knowing the target user’s password). A user can be blocked from using `sudo` until they appear in the sudo authorization rules.
Those rules live in the `sudoers` file, edited via `sudo vi /etc/sudoers` (with emphasis on using the correct method to avoid breaking access). The file defines who can run what commands, including group-based permissions. The lesson then creates a new group named `infinity gauntlet`, adds it to `sudoers` with broad command access (`ALL`), and removes the need for a password (`NOPASSWD`). Once `iron man` is added to that group, he can run `sudo` commands and perform high-impact actions.
Finally, the transcript demonstrates destructive account management using `userdel` (removing users like `thor`, `spider-man`, and others) and then “restoring” them by recreating accounts with `useradd`/`useradd`-style flows. The concluding security principle is least privilege: after the threat is neutralized, the group is deleted with `groupdel`, which removes the special sudo access by removing the group itself—preventing anyone from reusing the “gauntlet” permissions later.
Cornell Notes
Linux user management hinges on three linked pieces: account records in `/etc/passwd`, password hashes in `/etc/shadow`, and permission control via `sudo`. Creating users can be done with `adduser` (interactive, sets up more defaults like home directories) or `useradd` (more manual; may omit home directories and can default to `sh`). Passwords are set or changed with `passwd`, while account attributes like the login shell and username are adjusted with `usermod`. Privileged command execution is governed by `/etc/sudoers`, which can grant `sudo` rights to individual users or groups; the transcript uses a group called `infinity gauntlet` to demonstrate how quickly power can spread. Least privilege is enforced by deleting that group afterward with `groupdel`.
How can someone confirm which Linux user account they’re currently operating as, and where does Linux store the list of users?
What practical differences show up between `adduser` and `useradd` when creating accounts?
If a user exists but can’t log in properly or lacks expected defaults, which commands fix the common gaps?
Why is `sudo` safer than logging in as root, and how does `su` differ?
What controls whether a user can run `sudo`, and how does group-based permission work?
How does the transcript enforce least privilege after granting broad `sudo` power?
Review Questions
- What specific fields in `/etc/passwd` help determine a user’s identity and login environment (UID/GID, home directory, shell)?
- Describe a safe sequence to grant `sudo` access to a group and then revoke it using `sudoers` and `groupdel`.
- When would you use `adduser` versus `useradd`, and what follow-up commands might be required after `useradd`?
Key Points
- 1
User accounts are listed in `/etc/passwd`, while password hashes are stored in `/etc/shadow` and require `sudo` to view.
- 2
`adduser` is interactive and typically sets up defaults like home directories, while `useradd` is more manual and may require additional steps.
- 3
Use `passwd <username>` to set or change a user’s password, and `usermod` to change attributes like the default shell or username.
- 4
`sudo` provides temporary root-level command execution; `su` switches user identities and generally requires the target user’s password.
- 5
`/etc/sudoers` controls who can run `sudo`, and group entries can grant broad command access—so misconfiguration is dangerous.
- 6
Adding users to groups with `usermod -aG <group> <user>` is a common way to grant permissions without wiping existing group memberships.
- 7
Least privilege is maintained by removing the permission-granting group with `groupdel` once it’s no longer needed.