Users, root and sudo

Before you read. You bought the computer. You installed the operating system. Nobody else has ever logged into it. You try to save a file and it says Permission denied.

Denied by whom, exactly? And if you are the only person here, who is the system protecting the file from?

The answer is not “from you”. It is from a mistake you might make, which is a different thing and a more useful one.

Linux was built for machines with many users on them at once, and it never gave that up when it moved onto laptops. Every file belongs to somebody, every process runs as somebody, and the system checks before it acts. That check is the reason a bad command usually breaks one account rather than the whole machine.

Some words you will need

user account

An identity the system recognises. It owns files, runs programs, and has a numeric ID that the kernel actually uses.

root

The administrator account, user ID 0. Permission checks do not apply to it.

group

A named collection of users, so permission can be granted to several people at once without listing them individually.

UID and GID

The numeric user and group IDs. Names are for humans; the kernel compares numbers.

privilege escalation

Temporarily acting with more authority than your account normally has. sudo is the supported way to do it.

What breaks without this

You cannot administer anything. Installing software, editing anything under /etc, restarting a service, all of it needs privilege you do not have by default, and “permission denied” is where you stop until you understand why.

Or you overcorrect and run everything as root. This is the more expensive failure. Working as root means every typo executes with full authority, and the classic disasters all start this way.

You cannot answer the audit question. “Who made this change?” is a question with a real answer if people escalate through sudo, and no answer at all if everyone shares a root login. That is why objective 3.3 cares about this and not just objective 2.2.

Who are you?

Two commands. whoami gives the short answer, id gives the useful one:

# Debian 13 (trixie), x86_64
$ whoami; id; echo "--- now as sam ---"; su - sam -c "whoami; id"
root
uid=0(root) gid=0(root) groups=0(root)
--- now as sam ---
sam
uid=1000(sam) gid=1000(sam) groups=1000(sam)

Read the id line as three facts: who you are, what your primary group is, and every group you belong to.

uid=0 is the entire definition of root. Not the name. A user account named root with UID 500 would be an ordinary user, and an account named dave with UID 0 would have complete authority over the machine. The kernel compares the number.

That is also why “is there an account with UID 0 that should not be there” is a real security check, and a genuinely quick one.

The numbers are not arbitrary. 0 is root, low numbers are system accounts, and regular humans start at 1000 on most distributions. Sam is 1000, so sam was the first real person created on this machine.

What an account actually is

An account is a line in a text file. That is not a simplification.

# Debian 13 (trixie), x86_64
$ grep sam /etc/passwd; grep sam /etc/group; ls -ld /home/sam
sam:x:1000:1000::/home/sam:/bin/bash
sam:x:1000:
drwx------. 2 sam sam 57 Aug  8 00:30 /home/sam

Seven colon-separated fields, and you should be able to name them:

That x in field two matters. It is not the password and it is not an abbreviation for one. It is a marker saying “the hash lives in /etc/shadow”, which is a separate file that ordinary users cannot read. /etc/passwd has to be world-readable so that anything printing a username can look it up, and putting password hashes in a world-readable file was, in hindsight, not the finest hour of early Unix.

Field seven is worth a second look too. Setting a user’s shell to /usr/sbin/nologin is how you make an account that owns files and runs services but that nobody can log into. Scroll back to the /etc/passwd output in lesson 05 and you will see most of the accounts on the system are exactly that.

ps -o pid,ruser,euser,comm -C passwd
grep -E '^(Uid|Gid):' /proc/self/status

What root can do

Everything. That is the whole answer, and it is worth being blunt about because people expect more nuance than there is.

Root skips the permission check. Not “root has permission to most things”, the check does not run. Root can read any file, delete any file, kill any process, and reformat the disk it is running from. There is no confirmation prompt because there is no authority above root to ask.

Here is what that feels like from the other side. Sam, an ordinary user, tries three things: read the password file, create a file in /etc, and escalate with sudo.

# Debian 13 (trixie), x86_64
$ su - sam -c "cat /etc/shadow"; su - sam -c "touch /etc/newfile"; su - sam -c "sudo whoami"
cat: /etc/shadow: Permission denied
touch: cannot touch '/etc/newfile': Permission denied
-bash: line 1: sudo: command not found

Two refusals and one surprise. Sam cannot read the password hashes and cannot create a file in /etc, both of which are correct and desirable.

The third line is a different kind of failure and worth noticing: sudo is not installed here at all. It is not part of the base system on every image. On a minimal container or a stripped install you may have to install it before you can use it, which is a chicken-and-egg problem you solve by being root already, or by booting into rescue.

sudo: borrowing authority for one command

sudo runs a single command as another user, defaulting to root, and then hands you straight back to your own account. Three things happen before it runs anything:

1. It checks the rules in /etc/sudoers and /etc/sudoers.d/, are you allowed to run this?
2. It asks for a password, yours, not root’s. That surprises people and it is the point: root’s password does not need to exist or be shared.
3. It logs the attempt, allowed or denied, with who, when, from where, and what.

Ask for something you are not entitled to and it says so:

# Debian 13 (trixie), x86_64
$ su - sam -c "echo notarealpassword | sudo -S whoami"
[sudo] password for sam: sam is not in the sudoers file.

The password was accepted. That is sam’s real password. The refusal is about authorisation, not authentication. Sam proved who they were and the answer was still no, which is exactly the distinction the security domain of this exam keeps returning to.

The fix is not to hand out root’s password. It is to put sam in the group that the sudo rules already trust:

# Debian 13 (trixie), x86_64
$ usermod -aG sudo sam; id sam; su - sam -c "echo notarealpassword | sudo -S true 2>/dev/null; sudo whoami; sudo touch /etc/newfile; ls -l /etc/newfile"
uid=1000(sam) gid=1000(sam) groups=1000(sam),27(sudo)
root
-rw-r--r--. 1 root root 0 Aug  8 00:21 /etc/newfile

Three things to read out of that.

id sam now shows 27(sudo) alongside sam’s own group. That group membership is the whole grant, no file was edited, no password was shared.

sudo whoami printed root. The whoami ran as root, then sam’s shell carried on as sam.

sudo touch /etc/newfile succeeded where the same command failed a moment ago, and the file it created is owned by root, because the command ran as root. That last point catches people out: files created under sudo belong to root, so a file you made this way may be one you cannot then edit normally.

Only one password prompt appears for three sudo commands. sudo caches your authentication for a few minutes, fifteen by default, per terminal. Convenient, and also the reason an unlocked laptop with a recent sudo in its history is more dangerous than it looks.

Notice that flag combination, because leaving one letter off it is destructive. -G sets the complete list of supplementary groups; -a means append to the list rather than replace it. Sam here starts out in three groups besides their own.

# Debian 13 (trixie), x86_64
$ id sam; usermod -G sudo sam; echo "--- after usermod -G sudo sam ---"; id sam
uid=1000(sam) gid=1000(sam) groups=1000(sam),4(adm),1001(deploy),1002(webdev)
--- after usermod -G sudo sam ---
uid=1000(sam) gid=1000(sam) groups=1000(sam),27(sudo)

su, su -, and sudo -i

Three ways to become somebody else, and the differences are not cosmetic.

The dash is doing the work in su. Without it you take on the new identity but keep the environment you arrived with:

# Debian 13 (trixie), x86_64
$ cd /root; su sam -c "pwd; echo \$HOME"; echo "--- now with the dash ---"; su - sam -c "pwd; echo \$HOME"
/root
/home/sam
--- now with the dash ---
/home/sam
/home/sam

Without the dash sam is standing in /root, a directory sam cannot even list. With the dash sam starts in sam’s own home, as a real login would.

The environment difference is worse than the directory one:

# Debian 13 (trixie), x86_64
$ su sam -c "echo \$PATH"; echo "--- now with the dash ---"; su - sam -c "echo \$PATH"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
--- now with the dash ---
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Look at what disappears. The first PATH has /usr/sbin and /sbin in it, because it was inherited from root. The second does not, because that is what sam’s own login gets.

This is the source of an entire genre of confusion. You su to root without the dash, type an admin command, and get command not found, for a command that is definitely installed. It is in /usr/sbin, and your inherited PATH never looked there. The command exists, you have the privilege to run it, and the shell cannot find it.

Use the dash. su - and sudo -i both give you a clean login environment, which is the one that matches what documentation assumes.

Across distributions

Ubuntu’s choice is worth understanding rather than memorising. It ships with root’s password locked, so su - cannot work at all and sudo is the only route in.

Debian asks, which means the answer is whatever the installer was told. Give it a root password and you get the old behaviour, a working su - and an account you can log into. Leave that prompt empty and Debian disables the account and installs sudo instead, which is how you end up with a Debian machine that behaves like an Ubuntu one. So “Debian enables root” is a habit rather than a fact, and the machine in front of you is the only thing that settles it.

Same package, different policy, and a habit built on one distribution will mislead you on the other.

Prove it

After granting or changing access, three checks:

# Did the group membership actually land
id sam

# What is this user allowed to run, according to the rules themselves
sudo -l -U sam

# Is the escalation being recorded
journalctl _COMM=sudo -n 20

sudo -l is the one people skip. It reports what the sudoers rules permit rather than what you assume they permit, and the two differ more often than you would like.

What trips people up

1. Permission denied on your own machine

Owning the hardware grants you nothing. The kernel checks the UID of the process, and your interactive shell runs as you, not as root.

id tells you who you currently are. If the answer is not root and the file belongs to root, sudo is the answer, not chmod 777, which “fixes” it by removing the protection from everybody at once.

2. “is not in the sudoers file”

Sometimes followed by This incident will be reported, which sounds far more ominous than it is. It means a log line was written.

The message means you authenticated correctly and are not authorised. Adding the user to wheel or sudo is the usual fix, and note the two group names are different on different distributions, which is the most common reason a correct-looking usermod changes nothing.

One catch: group membership is read at login. Add yourself to a group and your current shell will not have it. Log out and back in, or check with id and believe the output rather than the usermod that appeared to succeed.

3. Files created under sudo belong to root

sudo touch report.txt in your own home directory makes a file you cannot then edit. Nothing is broken; the file’s owner is root because the process that made it was root.

sudo chown sam:sam report.txt fixes it. The wider habit is to notice when you are escalating for a command that did not need it.

4. Redirection happens before sudo does

This one is genuinely counter-intuitive:

sudo echo "127.0.0.1 test" > /etc/hosts

That fails with Permission denied, and people conclude sudo is broken. It is not. Your shell sets up the redirection before sudo ever runs, so the file is opened by your unprivileged shell. The echo would have run as root, but it never gets that far.

sudo tee -a /etc/hosts is the usual fix, because then the privileged process is the one doing the writing.

5. Being root all the time because it is easier

It is easier, briefly. Then every typo runs with full authority, every script you try runs with full authority, and nothing in your shell history can be attributed to a person.

The discipline is not superstition. sudo in front of the commands that need it means the commands that do not need it cannot hurt you, which covers almost all of them.

Work it through

A new colleague needs to restart the web service on a Debian machine. You add them:

useradd -m -s /bin/bash jordan
usermod -aG wheel jordan

They log in, run sudo systemctl restart nginx, and get jordan is not in the sudoers file. Both of your commands succeeded and printed no errors.

Work out what happened before reading on.

The group is wrong for this distribution. wheel is the RHEL family’s admin group; Debian uses sudo. The usermod succeeded because Debian does have a wheel group defined, it just is not referenced by any sudoers rule, so membership of it grants precisely nothing.

Why no error? Because nothing was wrong from usermod’s point of view. It was asked to add a user to an existing group and it did. The mismatch is between the group you chose and the group the rules trust, and no single command is in a position to notice that.

How would you have caught it? sudo -l -U jordan asks the rules directly, and would have reported no permitted commands while id jordan looked perfectly healthy. Checking the grant rather than the group is the habit worth building.

The fix: usermod -aG sudo jordan, then have them log out and back in, because group membership is established at login. Then sudo -l as jordan to confirm.

And one more thing worth asking: should jordan have full sudo at all, when the job is restarting one service? A sudoers drop-in permitting exactly systemctl restart nginx grants the access the role needs and nothing else. That is the whole of least privilege, and objective 3.3 asks about it directly.

Try it

Optional, if you have a machine handy where you already have administrative access.

1. Run id. Name your UID, your primary group, and every supplementary group, and say which of those you did not expect.
2. Run sudo -l. Read what you are actually permitted to do.
3. Run whoami, then sudo whoami. Two words, and the difference is the entire lesson.
4. Run su - (with the dash) and then echo $PATH. Exit, run su without the dash, and compare. Explain the difference in /sbin.
5. Try sudo echo hello > /root/test.txt and watch it fail. Then work out which part of the line was not running as root.

Verification step. You have it when you can explain, without looking, why sudo command > file fails while sudo tee file works.

Check yourself

References

• id(1) - Linux man-pages project. Accessed 2026-08-07.
• su(1) - Linux man-pages project. Accessed 2026-08-07.
• passwd(5) - Linux man-pages project. Accessed 2026-08-07.
• useradd(8) - Linux man-pages project. Accessed 2026-08-07.
• sudo(8) - Sudo Project. Accessed 2026-08-07.
• sudoers(5) - Sudo Project. Accessed 2026-08-07.

Every block above with a distribution and architecture header was captured by running the command on a Debian 13 (trixie) container. Blocks without one are illustrative.