RH134 Chapter 13 — Recovering Superuser Access

Chapter Objective: Configure and audit privileged access using su and sudo, and recover a system where superuser access has been lost entirely.

Key commands: su -, sudo, visudo, sudo -l

What "Superuser Access" Means

The root account (UID 0) is exempt from most standard permission checks — it's the account everything else in RHEL treats as fully privileged. "Recovering superuser access" covers two very different scenarios: an authorized administrator temporarily needing root privileges for a task, and a genuinely locked-out system where nobody can authenticate as root at all.

🔵 Why It Matters Most day-to-day "superuser access" work is really about controlling and auditing sudo — actually losing root access entirely is rarer, and Chapter 12 already covered the boot-time recovery procedure for that specific emergency.

su vs. sudo

	`su`	`sudo`
Requires	The TARGET user's password	YOUR OWN password (by default)
Scope	Opens a full shell as another user	Runs one command with elevated privileges, then returns
Logging	Minimal	Every invocation logged to `/var/log/secure`
Granularity	All-or-nothing	Can be restricted to specific commands per user/group

# Switch to root, requires ROOT's password, starts a login shell
su -

# Run a single command as root, requires YOUR OWN password
sudo systemctl restart sshd

# Get an interactive root shell via sudo instead
sudo -i

✅ Tip — sudo Is Generally Preferred in Modern Practice Because sudo ties elevated actions to an individual's own credentials and logs each one, it gives much better accountability than shared root access via su — especially with multiple administrators on the same system.

Configuring sudo with visudo

# ALWAYS edit sudo configuration with visudo — never a plain editor
sudo visudo

# Grant a specific user full sudo access
sarah  ALL=(ALL)  ALL

# Grant a user sudo access to only specific commands
miguel  ALL=(ALL)  /usr/bin/systemctl restart httpd, /usr/bin/systemctl status httpd

# Allow a command WITHOUT prompting for a password
miguel  ALL=(ALL)  NOPASSWD: /usr/bin/systemctl status httpd

# Prefer a dedicated file per admin/team over editing the main file
sudo visudo -f /etc/sudoers.d/miguel

⚠️ Warning — Why visudo, Specifically visudo locks the file against simultaneous edits and — critically — validates the syntax before saving. A broken sudoers file edited with a plain text editor can lock EVERYONE out of using sudo, including you, until it's fixed by another means.

The wheel Group

Rather than adding individual sudoers entries per user, RHEL ships a commented-out rule granting sudo access to the entire wheel group — a common, simpler pattern for granting broad admin access.

# In /etc/sudoers, this line is often present (may need uncommenting):
%wheel  ALL=(ALL)  ALL

# Add a user to the wheel group to grant them full sudo access
sudo usermod -aG wheel sarah

# Confirm membership
groups sarah

🔵 Note Managing access through group membership (wheel) rather than individual sudoers entries scales better for a team — add or remove someone from the group instead of hunting through sudoers rules.

Auditing sudo Usage

# Show what commands YOU are currently allowed to run with sudo
sudo -l

# Review the sudo activity log
sudo grep sudo /var/log/secure

# Or, if using the journal exclusively
journalctl _COMM=sudo

✅ Tip — sudo -l Is a Fast Self-Check Before assuming a sudoers change worked (or didn't), sudo -l shows exactly what the current user is permitted to run — much faster than re-reading the raw sudoers file to trace the logic yourself.

When You're Actually Locked Out

If root's password is genuinely lost or no working sudo access exists at all, this becomes the boot-time recovery scenario covered in Chapter 12: interrupting GRUB, appending rd.break, remounting /sysroot read-write, and using chroot to reset the password — followed by touch /.autorelabel for SELinux.

⚠️ Warning — Physical/Console Access Required This recovery method requires interrupting the boot loader, which generally means physical console access (or console access to a VM/hypervisor) — it isn't something you can do remotely over a network connection to an already-running system.

🔵 Note — Broken sudoers Is a Different Problem A syntax error in /etc/sudoers that locks out sudo (but root's own password still works) doesn't require the full boot recovery procedure — simply su - to root directly and fix the file, or boot to rescue mode and edit it there.

Limiting Superuser Risk

Prefer sudo with narrowly scoped commands over broad, all-access grants where practical
Use group membership (wheel) for team-wide access instead of maintaining many individual entries
Always edit sudo configuration with visudo, never a plain editor
Periodically review sudo -l and the audit log for unexpected grants or activity
Treat direct root logins as something to minimize — individual accountability via sudo is generally the safer default

Key Terms for Chapter 13

root: The superuser account (UID 0), largely exempt from standard permission checks
su: Switches to another user's full shell, requiring that user's password
sudo: Runs a single command with elevated privileges, authenticated with the invoking user's own password
visudo: The safe, validating editor for sudoers configuration
wheel group: A group traditionally granted broad sudo access as a whole, rather than per-user
/etc/sudoers.d/: Directory for dedicated, per-user or per-team sudo configuration files

Review Questions

What is the key difference in whose password is required between su and sudo?
Why is sudo generally considered better for accountability than shared root access via su?
Why should sudo configuration always be edited with visudo rather than a plain text editor?
What is the advantage of granting access through the wheel group instead of individual sudoers entries?
What command shows the current user exactly what they're permitted to run with sudo?
If root's password still works but sudoers has a syntax error locking out sudo, is the Chapter 12 boot recovery procedure necessary? Why or why not?
What kind of access does the boot-time root password reset procedure require that makes it unsuitable for a fully remote fix?