The Ultimate Guide to Linux Users & Sudo: Mastering the “God Mode”

Imagine you walk into a nuclear power plant.

You are given a key card. This key card opens the front door, the cafeteria, and the bathroom. It does not open the door to the Reactor Control Room. It definitely does not let you press the big red button that says “EMERGENCY VENT.”

This is sensible. This is safe.

Now, imagine a different operating system. Let’s call it… “Windows 95.” In that world, everyone who walks into the building is given the Master Key. The janitor can vent the reactor. The intern can shut down the cooling pumps. A visitor can accidentally delete the entire blueprint database.

For a long time, that’s how personal computers worked. But Linux is different. Linux was built for the internet, for multi-user mainframes, and for uncompromising security.

In Linux, there is only one person with the Master Key. Everyone else is just a guest.

Today, on Week 2 Day 5 (Day 12), we are going to learn about The Root User, the sudo command, and the Principle of Least Privilege. If you master these concepts, you will understand the fundamental security model that powers 90% of the world’s servers.

If you ignore this day, you will eventually accidentally destroy your system. Guaranteed.

The Root User (UID 0) – The God of Linux

In the Linux world, there is a god. Its name is Root.

The root user is a special account that exists on every Unix-like system (Linux, macOS, BSD). It has absolute, unchecked, unrestricted power.

• It can read any file (even your encrypted private keys).
• It can delete any file (even the operating system kernel while it’s running).
• It can stop any process.
• It can format the hard drive.
• It can change the password of any other user without knowing the old one.

Technically, the root user is defined by its User ID (UID). While you might be UID 1000, Root is UID 0. The Linux kernel hard-codes this check. If it sees “UID 0,” it turns off all permission checks. It doesn’t ask “Are you sure?” It just obeys.

The “rm -rf /” Horror Story

There is a command that strikes fear into the heart of every SysAdmin: rm -rf /.

• rm: Remove.
• -r: Recursive (delete folders and everything inside them, all the way down).
• -f: Force (do not ask for confirmation for every single file).
• /: The Root Directory (the very start of your hard drive, containing everything).

If you run this as a standard user, Linux laughs at you. rm: cannot remove '/boot': Permission denied You can’t delete the OS. You’re just a guest.

If you run this as root, Linux deletes itself. It starts deleting /bin (where the commands live), then /boot (the kernel), then /usr (your apps). Eventually, it deletes the command rm itself, and the system crashes into a black void. There is no “Recycle Bin.” There is no “Undo.”

This is why we fear Root. And this is why, in modern Linux, you are not Root. You are a standard user who essentially borrows Root’s powers only when absolutely necessary.

The sudo Solution (SuperUser DO)

If being root is dangerous, but we sometimes need to install software (which requires writing to system folders like /usr/bin), what do we do?

Do we log out and log back in as Root? NO. That is slow, cumbersome, and leaves a “logged in as root” terminal open where one typo could kill the server.

We use sudo.

sudo stands for “SuperUser DO”. It is a magic spell that grants you “God Mode” for exactly one command.

How it Works: The Authentication Flow

1. The Command: You type sudo apt update.
2. The Gatekeeper: The system pauses. It asks for YOUR password (not the root password). It wants to verify that you are actually the person sitting at the keyboard.
3. The Authorization: The system checks a special configuration file (the /etc/sudoers file). It asks: “Is the user ‘student’ allowed to use sudo?”
4. The Execution:
   • If Yes: It temporarily elevates your privileges to UID 0, executes the command apt update, and then immediately drops you back down to a standard user.
   • If No: It denies you and logs the attempt.

The “Timestamp” Feature

You might notice that if you run sudo twice in a row, it doesn’t ask for a password the second time. sudo caches your credentials for 15 minutes (by default). This is for convenience, so you don’t have to type your password 50 times while setting up a server. After 15 minutes of inactivity, the gate closes, and you must authenticate again.

The First Time Lecture

The first time you ever run sudo on a new system, you get the famous lecture. It is a rite of passage.

We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

It sounds like something from Spiderman, but it is the ethos of Linux administration.

Basic User Management Commands

Before we dive deeper into permissions, we need to know who we are and how to identify users.

1. whoami

Simple, elegant, essential. It tells you your current effective username.

$ whoami
student

$ sudo whoami
root

Look closely at that output. When you ran it with sudo, the system replied root. For that split second, the command whoami didn’t know “student” existed. It was run by root.

2. id

This gives you the technical “passport details” of your user.

$ id
uid=1000(student) gid=1000(student) groups=1000(student),27(sudo),113(docker)...

Let’s decode this passport:

• uid (User ID): Your unique number. Root is 0. System services (like www-data) are usually 1-999. Real humans usually start at 1000.
• gid (Group ID): Your primary group. Usually, you have a group named after yourself.
• groups: The list of “clubs” you belong to.
  • Being in group 27(sudo) (on Debian/Ubuntu) or wheel (on Fedora/RHEL) is what gives you the power to use sudo.
  • Being in docker lets you run containers.

Creating and Managing Users

You are the admin now. You’ve been hired to manage a server, and you need to add your colleague, Bob.

The Great Debate: useradd vs adduser

This confuses everyone, even seniors.

• useradd: The low-level binary. It is “dumb.” If you run useradd bob, it creates the user, but:
  • It doesn’t create a home folder (/home/bob).
  • It doesn’t set a password (account is locked).
  • It sets the shell to /bin/sh (the basic, ugly shell) instead of /bin/bash.
  • Verdict: Avoid using this raw command unless you are writing a script.
• adduser: A friendly, interactive Perl script (standard on Debian/Ubuntu). It wraps around useradd to do the “human” things.
  • It asks for a password.
  • It creates the home directory.
  • It asks for Full Name, Room Number, Phone Number (you can just hit Enter to skip).
  • Verdict: Use this.

(Note: On Red Hat/Fedora/CentOS, useradd is smarter and works fine, but on Debian/Ubuntu, stick to adduser.)

1. Create a User

sudo adduser bob

Output:

Adding user `bob' ...
Adding new group `bob' (1001) ...
Adding new user `bob' (1001) with group `bob' ...
Creating home directory `/home/bob' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

2. The “Sudo” Club (Granting Admin Rights)

By default, Bob is a nobody. He cannot install software. He cannot edit system files. If he types sudo apt update, the system will throw an error: bob is not in the sudoers file. This incident will be reported.

(Side note: “Reported” usually just means an email is sent to the local root mailbox, which nobody reads, but it sounds scary).

To make Bob an admin, we must add him to the “Sudo Club.”

Ubuntu/Debian: The group is named sudo.

sudo usermod -aG sudo bob

Fedora/CentOS/RHEL: The group is named wheel.

sudo usermod -aG wheel bob

Breaking down the flags:

• -a (Append): Add the user to this group, but do not remove them from their other groups. CRITICAL. If you forget -a and just use -G, you will remove Bob from all other groups!
• -G (Group): Specify the group name.

3. Switching Users

You don’t need to log out to test Bob’s account.

su - bob

• su: Switch User.
• -: This little dash is important. It tells Linux to “Simulate a full login.” It loads Bob’s path variables, his shell settings, and goes to his home directory. Without the dash, you switch to Bob but stay in your current directory with your current environment variables, which causes bugs.

4. Delete a User

Bob got fired. He tried to delete the database.

sudo deluser bob

Warning: This removes Bob’s login, but leaves his files in /home/bob. This is usually a good default (you might need to retrieve his work).

If you want to “nuke” him completely (delete user AND files):

sudo deluser --remove-home bob

The Principle of Least Privilege

Why do we go through all this trouble? Why not just log in as root and save the hassle of typing sudo? Why not give everyone the password?

This is the Principle of Least Privilege (PoLP).

Definition: A user, program, or process should have only the bare minimum privileges necessary to do its job, and nothing more.

Scenario A: The “Always Root” User (The Bad Way)

You are logged in as Root. You are browsing the web or running a script you found on GitHub. You accidentally download a malicious script disguised as a PDF. The script runs. Because you are Root, the script is Root. The script installs a keylogger in your kernel, disables your firewall, hides itself in the system boot process, and starts mining crypto. Game Over.

Scenario B: The “Sudo” User (The Linux Way)

You are logged in as student. You run that same malicious script. The script runs. It tries to install a keylogger in the kernel. Linux Kernel: “HALT. You are UID 1000. You cannot touch /boot. Permission Denied.” The script fails. It crashes. Even if the script manages to run, it can only delete your documents. It cannot touch the system configuration, other users, or the kernel. The damage is contained.

Real-World Example: Web Servers

When you run a web server (like Apache or Nginx), it starts as root just long enough to open the network port (Port 80), but then it immediately transforms itself into a restricted user called www-data. Why? Because if a hacker compromises your website through a WordPress plugin bug, they become the user running the web server. You want them to be trapped inside the weak www-data account. You don’t want them to be root.

The Secret Files (/etc/passwd & /etc/shadow)

Where does Linux store users? It’s not a complex database; it’s just text files.

1. /etc/passwd (Public User List)

This file is readable by everyone on the system.

cat /etc/passwd

You’ll see lines like this: root:x:0:0:root:/root:/bin/bash student:x:1000:1000:Student,,,:/home/student:/bin/bash bob:x:1001:1001:Bob,,,:/home/bob:/bin/bash

The format is 7 fields separated by colons:

1. Username: student
2. Password Placeholder: x (It used to be the hash, but that was insecure).
3. UID: 1000
4. GID: 1000
5. Comment: Student,,, (Full name, phone, etc).
6. Home Directory: /home/student
7. Default Shell: /bin/bash (This determines what terminal you see).

2. /etc/shadow (Private Password Hashes)

This file is readable only by root.

sudo cat /etc/shadow

It contains the actual password hashes. student:$6$xyz123...:18900:0:99999:7:::

If a hacker gets this file, they can try to “crack” your passwords offline. That is why sudo permissions are so critical—to protect this file.

sudo vs su – Clearing the Confusion

You will often see su mentioned online.

• sudo <command>: Run one command as root, using your password. (Best Practice).
• su -: Switch User to root. This logs you in as root permanently (until you type exit). It requires the ROOT password.
• sudo -i or sudo su -: Simulate a root login, but use YOUR password to authenticate.

Pro Tip: If you have a long list of admin tasks to do and don’t want to type sudo every time, type sudo -i. You will get a root prompt (root@server:~#). Do your work. Then immediately type exit to drop back to safety.

Conclusion: You Are The Guardian

Understanding users and sudo is the moment you graduate from “computer user” to “System Administrator.”

You now understand that restrictions are not there to annoy you. They are there to protect you. Every time you type sudo, take a split second to pause. You are putting on the Crown of Root. You are entering the Reactor Control Room.

Type carefully.

Action Items for Day 12:

1. Run id and analyze your groups.
2. Run sudo cat /etc/shadow just to see the forbidden file (don’t edit it!).
3. Create a test user named “intern”, give them sudo rights, login as them (su - intern), run a command, and then delete them.