Get AI summaries of any video or article — Sign up free
sudo = POWER!! (managing users in Linux) // Linux for Hackers // EP4 thumbnail

sudo = POWER!! (managing users in Linux) // Linux for Hackers // EP4

NetworkChuck·
4 min read

Based on NetworkChuck's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

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?

The current account is identified with `whoami`. The system-wide list of user accounts is stored in `/etc/passwd`, which includes fields like username, UID/GID, home directory, and default shell. Password hashes are not stored there; they live separately in `/etc/shadow`.

What practical differences show up between `adduser` and `useradd` when creating accounts?

`adduser` is interactive and typically handles more setup automatically—prompting for password and other details and creating a home directory. `useradd` is more “lazy”: it can create the account entry, but may not set a password and may not create a home directory. In the transcript, the `useradd`-created account (`iron man`) ends up with a different default shell (`sh` instead of `bash`) until corrected with `usermod`.

If a user exists but can’t log in properly or lacks expected defaults, which commands fix the common gaps?

Passwords are set or changed with `passwd <username>`. Shell and other account attributes are adjusted with `usermod`, such as `usermod --shell /bin/bash <username>`. Home directory creation can be handled by using `useradd` options like `-m` (shown when adding `hulk`).

Why is `sudo` safer than logging in as root, and how does `su` differ?

`sudo` grants temporary root-level privileges for a specific command, reducing the risk of accidental system damage. Logging in as root is discouraged (“never log in as root”). `su` switches identities to another user and requires that user’s password; using `sudo su -` can switch to root without directly knowing the root password, but it still relies on `sudo` authorization.

What controls whether a user can run `sudo`, and how does group-based permission work?

Authorization is defined in `/etc/sudoers`. Editing it is done via `sudo vi /etc/sudoers` to avoid misconfiguration. The transcript shows that adding a user to a group (like `infinity gauntlet`) and then granting that group `sudoers` rules (e.g., `ALL=(ALL) NOPASSWD: ALL`) allows members to run any command with `sudo` without a password.

How does the transcript enforce least privilege after granting broad `sudo` power?

After using the `infinity gauntlet` group to regain control, the group is removed with `groupdel infinity gauntlet`. Deleting the group revokes the group-based `sudo` permissions, so the special access can’t persist.

Review Questions

  1. What specific fields in `/etc/passwd` help determine a user’s identity and login environment (UID/GID, home directory, shell)?
  2. Describe a safe sequence to grant `sudo` access to a group and then revoke it using `sudoers` and `groupdel`.
  3. When would you use `adduser` versus `useradd`, and what follow-up commands might be required after `useradd`?

Key Points

  1. 1

    User accounts are listed in `/etc/passwd`, while password hashes are stored in `/etc/shadow` and require `sudo` to view.

  2. 2

    `adduser` is interactive and typically sets up defaults like home directories, while `useradd` is more manual and may require additional steps.

  3. 3

    Use `passwd <username>` to set or change a user’s password, and `usermod` to change attributes like the default shell or username.

  4. 4

    `sudo` provides temporary root-level command execution; `su` switches user identities and generally requires the target user’s password.

  5. 5

    `/etc/sudoers` controls who can run `sudo`, and group entries can grant broad command access—so misconfiguration is dangerous.

  6. 6

    Adding users to groups with `usermod -aG <group> <user>` is a common way to grant permissions without wiping existing group memberships.

  7. 7

    Least privilege is maintained by removing the permission-granting group with `groupdel` once it’s no longer needed.

Highlights

Linux user identity is traceable end-to-end: `whoami` shows the active user, `/etc/passwd` lists accounts, and `/etc/shadow` holds password hashes.
`adduser` tends to create a usable environment automatically, while `useradd` can leave gaps like missing home directories and unexpected default shells.
`sudo` power is governed by `/etc/sudoers`; group-based rules can effectively turn many users into root-equivalent operators.
Editing `sudoers` incorrectly can lock out access, so the transcript emphasizes using `sudo vi /etc/sudoers` and watching for syntax errors.
The “Infinity Gauntlet” group demonstrates how quickly privileges spread—and how deleting the group with `groupdel` cleanly revokes that access.

Topics

  • User Accounts
  • sudoers
  • Group Permissions
  • Shell Management
  • Account Deletion

Mentioned

  • UID
  • GID
  • NOPASSWD