LFCA 23 🐧 The Root User and sudo
Every Linux system has a superuser. UID 0 — root — is the account with no restrictions. It can read any file, write any file, kill any process, mount any filesystem, and change any permission. The kernel treats UID 0 as exempt from the checks that apply to every other user. This power is necessary: someone has to install software, configure the network, and manage user accounts. But it is also the single greatest risk on the system. A mistake made as root is not caught by the kernel — there is no permission check to fail, no error to stop it. The command runs exactly as written, even if it is destructive. The modern answer to this problem is sudo, a tool that grants specific users the ability to run specific commands with root’s privileges, without ever giving them root’s password and without requiring them to log in as root. This chapter covers what root is, why direct root login is discouraged, how sudo works, the sudoers file that defines its rules, and the habits that keep administrative access safe.
Key point: The root user has UID 0 and is exempt from most permission checks. Logging in as root or switching to root with su grants unrestricted access with no audit trail of who did what. sudo solves both problems: it grants elevated privileges for specific commands, it authenticates the user with their own password rather than root’s, and it logs every command that runs through it. The rules live in /etc/sudoers, which should only be edited with visudo to prevent syntax errors that could lock everyone out.
What root is, and why direct login is dangerous
Root is not a normal user with extra permissions. It is the account the kernel treats specially. When a process runs with effective UID 0, the kernel skips the permission checks that would otherwise apply. File permissions become advisory — root can read a file with mode 000 and write to a file owned by another user. This is by design: someone has to be able to repair the system when permissions are wrong or files are corrupted.
Why this makes root dangerous. The same exemption that lets root repair a broken system lets root destroy a working one. There is no safety net. rm -rf / runs because the kernel does not stop it. A mistyped path in a configuration command takes effect immediately. The system does not ask “are you sure?” because root is assumed to know what it is doing. The assumption is frequently wrong — every experienced administrator has a story about a command run as root that did something unintended.
Why logging in as root is discouraged. When you log in as root directly, every command you type runs as root. There is no separation between the ordinary work of navigating files and the administrative work of changing them. The danger is not that you will run a destructive command on purpose; it is that you will run an ordinary command in the wrong directory or with the wrong argument, and root will execute it without complaint. Running as a normal user and elevating only when needed creates a natural pause: the sudo prefix is a conscious decision to use root’s power.
Why su is better than direct login but still not ideal. su switches your identity to root after entering root’s password. It is better than logging in as root because you can start as yourself, but it has two problems. First, it requires sharing root’s password among everyone who needs administrative access. If one person leaves the organization, the password must be changed for everyone. Second, it provides no audit trail. Once you su to root, every command runs as root, and the system logs show only that a shell was opened as root — not who opened it or what they did. The sudo approach solves both problems .
How sudo works
sudo stands for “superuser do.” It allows a permitted user to run a command as another user, typically root, without knowing that user’s password. The user authenticates with their own password, and sudo checks a configuration file called /etc/sudoers to determine whether the command is allowed .
The flow is straightforward. You type sudo followed by the command you want to run as root. sudo prompts for your password — not root’s. It then consults /etc/sudoers to see whether you are permitted to run that command. If you are, the command executes with root’s privileges. If not, sudo prints an error and the command does not run .
Why authentication uses the invoking user’s password. This is the core security improvement over su. Each administrator has their own password, and no one needs to know root’s password except the person who set it during installation. When an administrator leaves, their account is disabled, and their ability to use sudo disappears with it. There is no shared secret to rotate. The system knows exactly which human account made each sudo request .
Why sudo caches credentials. After the first successful authentication, sudo remembers that you authenticated for a short period — typically 15 minutes — so you do not have to type your password for every command . This cache is per-terminal by default, so authenticating in one terminal does not grant passwordless sudo in another . The cache is stored in a timestamp file, and sudo -k clears it immediately, forcing re-authentication . The timeout is configurable through timestamp_timeout in the sudoers file.
Why every command is logged. sudo records the command, the arguments, the user who invoked it, and the time it ran. The default log destination is the system log, but sudoers can be configured to write to a dedicated file with Defaults logfile="/var/log/sudo.log" . This audit trail is the second major improvement over su. If something goes wrong, the log shows who ran what. If someone misuses their privileges, the evidence is there .
Why sudo restricts what can be run. Unlike su, which grants full root access once authenticated, sudo can be configured to allow only specific commands. A developer might be permitted to restart the web server but not to modify user accounts. An operator might be allowed to manage backups but not to install packages. This is the principle of least privilege applied to administrative access: grant only what is needed, nothing more .
The sudoers file
The rules that govern sudo live in /etc/sudoers. The file is plain text, and its syntax is precise. Each rule grants a user or group permission to run certain commands on certain hosts as certain users.
The basic rule format is:
user host=(runas) commandThe user is the username or a %group. The host is the hostname where the rule applies (ALL for any host). The runas is the user the command runs as (root or ALL). The command is the absolute path to the executable, with ALL for any command .
A simple example: alice ALL=(ALL) ALL grants Alice permission to run any command as any user on any host. The common configuration for an administrator group is %wheel ALL=(ALL) ALL, which grants every member of the wheel group full sudo access .
Why visudo is mandatory. /etc/sudoers cannot be edited with a normal text editor. A syntax error in the file can break sudo entirely, leaving no way to run administrative commands. visudo opens the file in an editor, and when you save, it validates the syntax before writing. If the syntax is wrong, it warns you and lets you fix it or discard the changes . This is the single most important habit for anyone who configures sudo.
Why /etc/sudoers.d/ exists. Adding rules directly to /etc/sudoers mixes custom configuration with the distribution’s defaults. The #includedir /etc/sudoers.d directive tells sudo to read additional files from that directory, and this is where custom rules belong . Each file can be created with visudo -f /etc/sudoers.d/filename, which gives the same syntax checking as editing the main file. This keeps the configuration modular and makes it easier to review and remove individual rules.
Why file naming and ordering matter. Files in /etc/sudoers.d/ are read in alphabetical order. Prefixing filenames with numbers — 01_users, 10_services, 50_admins — makes the order explicit . If two files contain conflicting rules, the later one wins. Numbering makes the intended precedence visible.
Why the %wheel group is the common target. On most distributions, the wheel group is the traditional administrative group. Granting sudo to %wheel instead of to individual users means that adding or removing administrative access is a group membership change, not a sudoers edit. The rule stays stable, and the membership is managed separately .
Practical sudo configuration
The default configuration on most systems allows members of the sudo or wheel group to run any command. That is a reasonable starting point for a small team where every administrator is trusted equally. For larger environments, more granular rules are the norm.
A rule that allows a user to restart the web server without granting full root access looks like this:
webadmin ALL=(root) /usr/bin/systemctl restart nginxThe user webadmin can run that one command as root. Attempting to run anything else with sudo produces a “not allowed” error. This is the principle of least privilege in practice .
A rule that allows a group to manage users without full root:
%useradmins ALL=(root) /usr/sbin/useradd, /usr/sbin/userdel, /usr/sbin/usermodThe members of useradmins can add, remove, and modify users, but cannot install packages, edit network configuration, or run arbitrary commands.
Why command paths must be absolute. sudoers requires the full path to each executable. A rule with useradd instead of /usr/sbin/useradd is a syntax error. The path pins the rule to a specific binary, which prevents a user from creating a script with the same name in their PATH and getting it executed as root .
Why passwordless sudo is sometimes configured. A rule with NOPASSWD: before the command list allows that user to run the listed commands without entering a password:
backup ALL=(root) NOPASSWD: /usr/local/bin/backup.shThis is used for automation — a scheduled backup job should not block waiting for a password prompt. It is also used for commands that are considered safe enough that the authentication step adds no security. The risk is real: if the account is compromised, the attacker can run those commands without knowing the password. Passwordless sudo should be limited to commands that cannot be abused to gain a shell or read sensitive files .
Why sudo -i and sudo su are different from sudo command. Running sudo command executes one command with elevated privileges and returns to your normal user. Running sudo -i starts a root login shell — you are now root for the rest of the session, and every command runs as root until you exit. This is sometimes necessary for a sequence of administrative tasks, but it reintroduces the problem that sudo was designed to solve: the safety pause is gone, and every command runs as root without the sudo prefix. Use sudo -i sparingly and exit promptly .
Complete Example Session
# ============================================
# PART 1: CHECK YOUR CURRENT IDENTITY
# ============================================
whoami
# alice
id
# uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo)
# ============================================
# PART 2: RUN A COMMAND WITH SUDO
# ============================================
sudo whoami
# [sudo] password for alice:
# root
# The command ran as root, but you authenticated as alice
# ============================================
# PART 3: SUDO CREDENTIAL CACHE
# ============================================
sudo whoami
# root
# (no password prompt — cached for 15 minutes)
sudo -k
# (clears the cache)
sudo whoami
# [sudo] password for alice:
# root
# (password required again)
# ============================================
# PART 4: VIEW SUDO LOGS
# ============================================
sudo journalctl -u sudo | tail -5
# (shows recent sudo invocations)
# alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ;
# COMMAND=/usr/bin/whoami
# ============================================
# PART 5: EDIT SUDOERS SAFELY
# ============================================
sudo visudo
# (opens /etc/sudoers in an editor)
# (on exit, syntax is validated)
# ============================================
# PART 6: CREATE A CUSTOM RULE
# ============================================
sudo visudo -f /etc/sudoers.d/10_webadmin
# (creates a new file with syntax checking)
# Inside the file:
# webadmin ALL=(root) /usr/bin/systemctl restart nginx
# ============================================
# PART 7: TEST THE RULE
# ============================================
su - webadmin
# (switch to the webadmin user)
sudo systemctl restart nginx
# [sudo] password for webadmin:
# (command runs successfully)
sudo cat /etc/shadow
# Sorry, user webadmin is not allowed to execute
# '/usr/bin/cat /etc/shadow' as root.
# (denied — the rule only permits systemctl restart nginx)
# ============================================
# PART 8: SU VS SUDO
# ============================================
su -
# Password:
# (enters root's password — you are now root)
# (every command runs as root; no per-command logging)
exit
# ============================================
# PART 9: GROUP-BASED SUDO
# ============================================
# Add alice to the wheel group
sudo usermod -aG wheel alice
# The rule in /etc/sudoers:
# %wheel ALL=(ALL) ALL
# ============================================
# PART 10: DISABLE ROOT SSH LOGIN
# ============================================
sudo grep PermitRootLogin /etc/ssh/sshd_config
# PermitRootLogin no
# ============================================
# PART 11: SECURITY AUDIT
# ============================================
# Who has sudo access?
sudo grep -E '^[^#].*ALL' /etc/sudoers /etc/sudoers.d/*
# (shows all active rules)
# Check sudo log
sudo journalctl -u sudo --since "1 hour ago" | tail -20Each part covers one aspect of sudo usage. Parts 1 through 4 show the basic flow. Parts 5 through 7 show configuration. Parts 8 through 11 show the comparison with su, group-based access, SSH hardening, and auditing.
Quick Reference
Identity and Elevation
| Command | What It Does |
|---|---|
whoami | Current username |
id | Current UID, GID, groups |
sudo command | Run one command as root |
sudo -i | Start a root login shell |
su - | Switch to root (needs root password) |
su - user | Switch to another user |
sudo Options
| Option | Effect |
|---|---|
sudo -k | Clear cached credentials |
sudo -l | List allowed commands |
sudo -v | Refresh cached credentials |
sudo -u user | Run as another user |
sudo -i | Root login shell |
sudo -s | Root shell (no login) |
sudoers Rule Format
| Part | Example | Meaning |
|---|---|---|
| User | alice or %wheel | Who the rule applies to |
| Host | ALL | Where it applies |
| Runas | (root) or (ALL) | What user to run as |
| Command | /usr/bin/systemctl | Absolute path |
sudoers File Locations
| Location | Purpose |
|---|---|
/etc/sudoers | Main configuration |
/etc/sudoers.d/ | Custom rule files |
/var/log/sudo.log | Optional dedicated log |
su vs sudo
| Aspect | su | sudo |
|---|---|---|
| Password | Target user’s | Your own |
| Scope | Full identity switch | Per-command (default) |
| Audit | Minimal | Per-command logging |
| Granularity | All or nothing | Command-by-command |
| Root password shared | Yes | No |
Security Hardening
| Measure | Purpose |
|---|---|
PermitRootLogin no | Disable SSH as root |
%wheel group | Group-based sudo |
visudo only | Prevent syntax errors |
timestamp_timeout=5 | Shorter credential cache |
NOPASSWD limited | Only for safe automation |
| Log sudo commands | Audit trail |
Best Practices
✅ Do This:
# Always use visudo for sudoers changes
sudo visudo # ✅
# Use /etc/sudoers.d/ for custom rules
sudo visudo -f /etc/sudoers.d/10_webadmin # ✅
# Grant sudo to groups, not individuals
%wheel ALL=(ALL) ALL # ✅
# Use the most specific command paths
webadmin ALL=(root) /usr/bin/systemctl restart nginx # ✅
# Clear credentials when stepping away
sudo -k # ✅
# Disable direct root SSH login
PermitRootLogin no # ✅
# Check sudo access with sudo -l
sudo -l # ✅❌ Don’t Do This:
# Don't edit /etc/sudoers directly
vim /etc/sudoers # syntax error locks you out # ⚠️
# Don't share root's password
# Use sudo with individual accounts # ⚠️
# Don't grant NOPASSWD to dangerous commands
backup ALL=(root) NOPASSWD: /bin/bash # shell access # ⚠️
# Don't use su - when sudo works
su - # requires root password, no per-command audit # ⚠️
# Don't leave a root shell open
sudo -i # exit when done # ⚠️
# Don't log in as root directly
# Use your own account and sudo # ⚠️Common Pitfalls
| Pitfall | Problem | Solution |
|---|---|---|
| Editing sudoers with vim | Syntax error locks out sudo | Use visudo |
| Forgetting absolute paths | Rule rejected or ineffective | Full path to executable |
Using su instead of sudo | No audit trail, shared password | Prefer sudo |
| NOPASSWD on shell commands | Passwordless root shell | Limit to safe commands |
Not checking sudo -l | Unsure of permissions | Run sudo -l |
| Credential cache on shared terminal | Another user inherits sudo | Use sudo -k after use |
| Granting ALL=(ALL) ALL by default | Over-privileged users | Grant specific commands |
| Leaving root shell open | Full root access unattended | Exit when done |
Real-World Examples
1. Check what you can run with sudo
sudo -l2. Run a single command as root
sudo systemctl restart nginx3. Open a root shell for a sequence
sudo -i4. Clear cached credentials
sudo -k5. Create a granular rule
sudo visudo -f /etc/sudoers.d/10_webadmin6. Grant sudo to a group
%wheel ALL=(ALL) ALL7. Allow a specific command without password
backup ALL=(root) NOPASSWD: /usr/local/bin/backup.sh8. Disable root SSH login
sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config9. Check who has sudo access
sudo grep -E '^[^#]' /etc/sudoers /etc/sudoers.d/*10. View sudo audit log
sudo journalctl -u sudo --since "1 hour ago"Visual: su vs sudo
┌──────────────────────────────────────────────────────────┐
│ su - │
│ │
│ You type: su - │
│ Password: <ROOT PASSWORD> │
│ │ │
│ ▼ │
│ You are root. Every command runs as root. │
│ No per-command logging. One shared secret. │
│ │
├──────────────────────────────────────────────────────────┤
│ sudo command │
│ │
│ You type: sudo systemctl restart nginx │
│ Password: <YOUR PASSWORD> │
│ │ │
│ ▼ │
│ sudo checks /etc/sudoers. │
│ │ │
│ ├── Allowed ──► command runs as root │
│ │ (logged: who, what, when) │
│ │ │
│ └── Denied ──► error, command does not run │
│ │
│ You return to your normal user after the command. │
│ │
└──────────────────────────────────────────────────────────┘Visual: sudoers Rule Anatomy
┌──────────────────────────────────────────────────────────┐
│ %wheel ALL = (ALL) ALL │
│ │ │ │ │ │
│ │ │ │ └── Command: ALL commands │
│ │ │ └── Runas: as ANY user │
│ │ └── Host: on ANY host │
│ └── User: % group "wheel" │
│ │
├──────────────────────────────────────────────────────────┤
│ webadmin ALL = (root) /usr/bin/systemctl restart nginx│
│ │ │ │ │ │
│ │ │ │ └── ONE specific command │
│ │ │ └── Runas: ONLY as root │
│ │ └── Host: ANY │
│ └── User: webadmin (individual) │
│ │
└──────────────────────────────────────────────────────────┘Visual: sudo Credential Cache
┌──────────────────────────────────────────────────────────┐
│ sudo whoami │
│ [sudo] password for alice: ****** │
│ root │
│ │ │
│ ▼ │
│ Timestamp written to /var/run/sudo/ts/alice │
│ │ │
│ ▼ │
│ sudo apt update │
│ (no password — cached) │
│ │ │
│ ▼ │
│ ... 15 minutes pass ... │
│ │ │
│ ▼ │
│ sudo whoami │
│ [sudo] password for alice: │
│ (cache expired — password required) │
│ │
│ sudo -k clears the cache immediately. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Where sudoers Rules Live
┌──────────────────────────────────────────────────────────┐
│ /etc/sudoers (main file — edit with visudo) │
│ │ │
│ │ #includedir /etc/sudoers.d │
│ │ │ │
│ ▼ ▼ │
│ /etc/sudoers.d/ │
│ ├── 01_users (read first) │
│ ├── 10_webadmin (read second) │
│ ├── 50_admins (read third) │
│ └── 99_local (read last — wins conflicts) │
│ │
│ Files are read alphabetically. │
│ Later files override earlier ones. │
│ Numbering makes the order explicit. │
│ │
└──────────────────────────────────────────────────────────┘Visual: The Safety Pause
┌──────────────────────────────────────────────────────────┐
│ WITHOUT SUDO (logged in as root) │
│ │
│ $ cd /etc │
│ $ ls │
│ $ rm -rf nginx/ │
│ │ │
│ └── Deleted immediately. No prompt. │
│ │
├──────────────────────────────────────────────────────────┤
│ WITH SUDO (logged in as normal user) │
│ │
│ $ cd /etc │
│ $ ls │
│ $ sudo rm -rf nginx/ │
│ │ │
│ ├── [sudo] password for alice: │
│ │ (you pause, think, decide to proceed or not) │
│ │ │
│ └── If you proceed, it is logged. │
│ │
│ The sudo prefix is a conscious decision. │
│ │
└──────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Root UID | 0 |
| Root privileges | Exempt from permission checks |
| Direct root login | Discouraged |
| su password | Target user’s (often root) |
| sudo password | Invoking user’s |
| sudo cache duration | 15 minutes (default) |
| sudoers file | /etc/sudoers |
| Custom rules | /etc/sudoers.d/ |
| Editor | visudo only |
| Audit | Per-command logging |
Key takeaways:
- Root is UID 0 and is exempt from permission checks — this is what makes it powerful and what makes it dangerous
- Direct root login and
sugrant unrestricted access with minimal audit — they are the old way, and they are discouraged sudoauthenticates with the invoking user’s password, not root’s, so no shared secret is neededsudologs every command it runs, creating an audit trail thatsudoes not providesudogrants per-command privileges, not a full identity switch, which is the principle of least privilege in practice- The
sudoersfile defines the rules, and it must only be edited withvisudoto prevent syntax errors that lock out administrative access - Custom rules belong in
/etc/sudoers.d/, not in the main file, with numbered prefixes to control read order - sudo caches credentials for a short period — 15 minutes by default — so repeated commands do not require repeated passwords
NOPASSWDshould be limited to safe automation commands — granting it to a shell is equivalent to granting passwordless root- Disabling root SSH login and using
sudowith individual accounts is the standard secure configuration for administrative access
Remember: The root account is necessary and dangerous in equal measure. sudo exists to give administrators the access they need without the risks of shared passwords, unrestricted sessions, and missing audit trails. The habit that matters most is the one sudo enforces: pausing before running a command as root, because the command will do exactly what it says. Configure sudoers with visudo, grant the narrowest privileges that get the job done, log everything, and never share root’s password.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!