LAB-USER-03 - The Almighty Sudo

Part A: The Field Guide

---

🎯 What & Why

Historically, if a junior sysadmin needed to restart the web server, you had to give them the root password. This was terrifying. If they had the root password, they could also read the CEO’s emails, wipe the hard drives, or lock you out of the server.

sudo (Super User DO) was invented to solve this.

It operates on the principle of Delegation. Instead of giving someone the master key to the entire building (Root), sudo acts like a bouncer at a security gate. When a user asks to do something restricted, the bouncer checks a guest list (the /etc/sudoers file). The list might say: “Dave is allowed to restart the Nginx server, but NOTHING else.”

sudo allows you to execute commands as another user (defaulting to root), while using your own password for authentication. Accountability, traced.

---

🧠 Mental Model: The Sudoers Syntax

The rules defining who can do what are stored in /etc/sudoers. Reading this file feels like reading hieroglyphics. Let’s decipher a standard rule.

bob    ALL=(root)    /bin/systemctl restart nginx

Here is the translation, read from left to right:

1. bob: WHO is asking? (The user Bob).
2. ALL=: WHERE are they asking from? (ALL means this rule applies on any server parsing this file).
3. (root): AS WHOM are they executing it? (Bob is allowed to impersonate Root).
4. /bin/systemctl restart nginx: WHAT are they allowed to do? (Exactly and specifically this command, nothing else).

If Bob logs in, he cannot run systemctl stop nginx. He cannot run cat /etc/shadow. If he attempts them, the bouncer will reject him and log a security alert. He can only restart Nginx.

---

📖 Command Reference

sudo — Temporary Elevation

Executes the following command with root privileges (if authorized).

sudo -l — What am I allowed to do?

Lists the specific privileges granted to your current user. Invaluable when logging into a new system.

(If you see ALL : ALL, it means you have unrestricted, god-tier admin access).

visudo — The Only Safe Way to Edit

You must NEVER edit /etc/sudoers with nano or vim directly.

If you make a syntax typo in /etc/sudoers and save it, the sudo command breaks instantly. Since you need sudo to fix the file, you are permanently locked out of admin rights on your own server. You have bricked the machine.

visudo is a specialized wrapper. When you run sudo visudo, it opens a temporary copy of the file. When you save and exit, it runs a strict syntax check. If there is a typo, it warns you and refuses to apply the changes, saving the server from death.

---

🌍 Real Scenarios

Scenario 1: The “No Password” Automation You have a deployment script that needs to restart the web server automatically via SSH. If the script gets prompted for a password, it will hang forever. You use visudo and add the NOPASSWD: tag: deploy_user ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx Now the script can run sudo systemctl restart nginx silently, without prompting.

Scenario 2: Delegating to Groups Instead of naming individual users, you delegate to an entire group. In /etc/sudoers, group names are preceded by a %. %webadmins ALL=(ALL) /bin/systemctl reload apache2 Now, anytime you add a user to the webadmins group (usermod -aG webadmins dave), they instantly gain that power.

Scenario 3: I forgot sudo! You type out a massive, 200-character configuration command, hit Enter, and get Permission denied. You forgot to put sudo at the front. Instead of re-typing it, you use the legendary history expansion trick: sudo !! This tells bash “run sudo, and append the entirety of my previous command to it.”

---

⚠️ Gotchas & Pitfalls

1. Typing su versus sudo
   • su (Switch User) asks for the TARGET user’s password. (su root requires the root password).
   • sudo asks for YOUR personal password to authorize the action.
2. Redirections and Sudo
   • 🔴 Fails: sudo echo "127.0.0.1 test" >> /etc/hosts
   • Why? Because sudo applies to echo. It prints text with root power. Then, the shell (running as normal you) tries to take that text and append it >> to /etc/hosts. The redirection fails with Permission Denied.
   • 🟢 Succeeds: echo "127.0.0.1 test" | sudo tee -a /etc/hosts > /dev/null
   • (The tee command is running under sudo and has the power to write the file).
3. The 15-Minute Timeout
   • After typing your password for sudo, the bouncer remembers you for 15 minutes. You won’t be prompted again during that window. To force the bouncer to forget you immediately (useful before leaving your desk), type sudo -k (kill credentials).

---

Part B: The Drill Deck

Terminal Required: Open your Linux terminal for these exercises.

---

G

Guided Step by step - type exactly this and compare the result

>

Exercise G1: Finding Out How Powerful You Are

1. Open your terminal. Let’s see your actual clearance level.
2. Run: sudo -l (Type your password if prompted).
3. Do you see (ALL : ALL) ALL? If so, you are a full administrator.
4. Now, check if a fake user has power: sudo -l -U fake_user. It should say “User fake_user is not allowed to run sudo”.

Exercise G2: Forcing a Password Prompt

1. If you just ran sudo -l, the system will remember your password for 15 minutes. A sudo cat /etc/shadow will work instantly.
2. Let’s invalidate that ticket. Run: sudo -k
3. Now run: sudo cat /etc/shadow
4. Notice how you are immediately asked for your password again! It is an excellent security habit to run sudo -k before locking your screen.

Exercise G3: The Safe Editor

1. Run: sudo visudo.
2. Look at the file structure. Look for the root user line. Look for the %sudo or %wheel group line. (This line is why adding people to the sudo group gives them admin powers!)
3. DO NOT MAKE CHANGES. Just exit safely.
   • If it opened in nano, press Ctrl+X.
   • If it opened in vi/vim, type :q! and press Enter.

S

Solo Task described, hints available - figure it out

>

Exercise S1: The Redirection Problem

1. Run cat /etc/hostname to see your machine name.
2. Try to append a comment to the end of that file using bash redirection: sudo echo "# This is my computer" >> /etc/hostname
3. Notice the “Permission Denied” error! Understand why it failed (the >> runs as you, not root).
4. Now, use the tee command trick to safely append it with root power: echo "# This is my computer" | sudo tee -a /etc/hostname > /dev/null
5. Verify it worked: cat /etc/hostname

Exercise S2: The Last Command Trick

1. Try to read the master hash file without sudo: cat /etc/shadow
2. You get Permission Denied.
3. Use the history expansion shortcut to replay it with sudo instantly: type sudo !! and hit Enter.

M

Mission Real scenario - no hints, combine multiple skills

>

Mission M1: Delegated Power

Your mission is to grant a test user the ability to restart system processes, but absolutely nothing else.

1. Create a dummy user: sudo useradd -m ops_intern
2. We want ops_intern to be able to run sudo systemctl restart cron without needing a password.
3. Use sudo visudo to open the configuration.
4. Carefully append this exact line at the very bottom: ops_intern ALL=(ALL) NOPASSWD: /bin/systemctl restart cron
5. Save and exit visudo.
6. Test your work! Switch to the intern: sudo su - ops_intern
7. Try to run: sudo cat /etc/shadow. It should reject them!
8. Try to run: sudo systemctl restart cron. It should succeed, with no password prompt!
9. Exit out of the intern shell (exit), drop into visudo again, remove the line, and sudo userdel -r ops_intern.

You are now managing granular permissions like an enterprise security engineer.