LAB-USER-06 - Switching Identities: su vs su -

Part A: The Field Guide

---

🎯 What & Why

You know you can use sudo to run a single command as another user. But what if you need to run 50 commands configuring a database? Tying sudo before every single command is exhausting.

You need to step into the skin of the other user and stay there.

We use the su (Switch User) command for this. However, su has a subtle, invisible trap that plagues beginners and causes mysterious “command not found” errors: The Environment.

When you put on someone else’s coat, do you empty their pockets and put your own stuff inside, or do you keep their stuff? The difference between su bob and su - bob defines whether you get Bob’s environment, or keep your own.

---

🧠 Mental Model: The Environment Backpack

Whenever you log into a Linux system, the OS hands you a “Backpack” called your Environment. This backpack contains variables like:

• USER (Who you are)
• PWD (Where you currently are)
• HOME (Where your home directory is)
• PATH (The list of folders where Linux searches for commands when you type them).

Trap #1: su root (The Partial Switch)

If you type su root, your physical identity changes to root. You get root’s permissions. But you keep your original backpack. You keep your PATH. You stay in your current directory. If an admin command exists in /sbin (root’s territory), but /sbin isn’t in your normal user’s PATH backpack, you type the command and Linux says Command not found. You become frustrated because you are root, but the tools are broken!

Trap #2: su - root (The Full Login)

The tiny hyphen - changes everything. It means Simulator Login. If you type su - root, you change to root’s identity, you throw away your backpack, and you accept root’s backpack. You are teleported to /root (root’s home). Your PATH updates to include root’s admin folders. You load root’s .bashrc settings. It is a completely pure, isolated simulation of logging in through SSH directly as root.

---

📖 Command Reference

su - (Switch to Root cleanly)

If no username is provided, su assumes you want to become root. It will prompt for the Root account’s password. (On Ubuntu, the root password is locked by default, so this might fail).

su - username (Switch to a User)

Switch into another human or service account.

sudo su - (The Ultimate Combo)

If you don’t know the Root password, but you have sudo privileges, you can combine them. You are executing the “Switch User” command using your own sudo powers.

This drops you exactly into a pure root shell, bypassing the need for a shared root password. This is the modern standard for becoming root.

---

🌍 Real Scenarios

Scenario 1: Setting up Postgres You install the PostgreSQL database. It creates a system user called postgres. This user owns the database. You, as your normal user, try to run psql to manage the database and it fails with “authentication failed.” You must become the database: sudo su - postgres You are now inside the postgres user, with all its paths loaded. psql now works seamlessly.

Scenario 2: The Malicious Bashrc You suspect user eve has altered her .bashrc file to launch malware the moment she logs in. You want to inspect her files, but if you run su - eve, her .bashrc will execute as part of the simulated login, and the malware attacks you! Instead, you run su eve (without the hyphen). You get her permissions, but your environment, skipping her .bashrc completely. This is the ONE rare time an advanced admin omits the hyphen.

---

⚠️ Gotchas & Pitfalls

1. Exit versus Ctrl+C — When you su - into another user, you are sinking one level deeper into an onion. To get back to your original self, you must type exit (or press Ctrl+D, which sends an End of File signal, effectively logging you out of the nested shell).
2. Nesting too deep — If you su - bob, then su - root, then su - charlie, you have 4 shells stacked on top of each other eating memory. You have to type exit 3 times to get back to your original prompt.

---

Part B: The Drill Deck

Terminal Required: Open your Linux terminal for these exercises. You will need sudo.

---

G

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

>

Exercise G1: Inspecting your Backpack

1. Before we switch, let’s look at a critical variable in your current backpack.
2. Run: echo $HOME. This prints the path to your home directory.
3. Run: pwd. Make sure you are in that directory.

Exercise G2: The Partial Switch (Bad)

1. Switch to root without the hyphen: sudo su
2. Notice your prompt might have changed. You are root (whoami will confirm).
3. Check your location: pwd. You did not move! You are still in your normal user’s directory.
4. Check the backpack variable: echo $HOME. It still says /home/yourusername!
5. This is a messy, blended environment.
6. Type exit to return to your normal user.

Exercise G3: The Full Switch (Good)

1. Let’s do it right. Switch to root with the hyphen: sudo su -
2. Check your location: pwd. You teleported directly to /root.
3. Check the backpack variable: echo $HOME. It now correctly says /root.
4. You have loaded a pure, simulated login environment.
5. Type exit to return to your normal user.

S

Solo Task described, hints available - figure it out

>

Exercise S1: Testing the Path

The $PATH variable dictates where Linux looks for commands without you typing absolute paths (like /bin/cp).

1. As your normal user, print your path contents: echo $PATH.
2. Notice it contains folders like /usr/local/bin and /usr/bin.
3. Switch to root purely (sudo su -).
4. Print the path again: echo $PATH.
5. Look closely. Notice that root has folders like /usr/sbin and /sbin near the front. The sbin folders hold Systems Binaries (admin commands). Normal users often don’t have these in their backpack!
6. exit back to normal.

Exercise S2: The Service Identity

1. Find the name of your web server user (usually www-data, or apache, or nginx) by checking /etc/passwd.
2. Try to perform a full simulated login into that user. Example: sudo su - www-data.
3. What happens?
4. If you paid attention in the previous labs, it will fail and terminate immediately. Why? Because service accounts are explicitly given a shell of /usr/sbin/nologin or /bin/false. You cannot log into them because they have no interactive shell to grant you!

M

Mission Real scenario - no hints, combine multiple skills

>

Mission M1: Forcing a Shell

In Exercise S2, you discovered you cannot su - into a system service user because their shell is set to /usr/sbin/nologin. This is a great security feature.

But what if you are debugging a complex permission issue, and you must test accessing a file exactly as the www-data web user to see if the webserver can read it?

You can force su to temporarily override the locked shell listed in /etc/passwd and hand the user a raw /bin/bash shell instead.

Research the su manual (man su or su --help). Find the flag used to specify a shell. Formulate and execute the command to successfully drop into an interactive bash prompt as www-data.

(Hint: Verify you succeeded by running whoami; it should print www-data. When finished, exit.)