Learn Linux - Administrator Access & Sudo Management

#Introduction

After episode 9 where we covered file permissions & ownership — the rwx bits, chmod 755 vs chmod 600, chown, through to SUID/SGID and the sticky bit on /tmp — you now understand that Linux controls who can read, write, and execute every file. But one big question remains hanging: how do you change system configuration, install packages, or manage services when all those important files are owned by root?

The answer isn't logging in as root all the time, but rather the principle of controlled privilege escalation: sudo. In this episode, we'll dissect why using root directly is dangerous, what the difference is between su - and sudo, how the sudoers configuration structure works, and how to grant — and revoke — administrative rights to users safely. This topic isn't just theory; a small mistake here can lock you out of your own server. Let's begin.

#Main Discussion

#Why Is Logging In Directly as root Dangerous?

Imagine driving a freight truck without brakes. Every command you run executes with full power, no confirmation, no limits, and no trace of who did what. That's roughly the experience of logging in directly as root: one typo like rm -rf /var instead of rm -rf /var/tmp immediately destroys the system, with nothing to hold it back.

There are three technical reasons why logging in as root is a big danger:

1. No security boundary (maximum blast radius). When a program runs as root, an exploit in that program automatically gives an attacker full access to the entire machine. Conversely, a program running as a regular user can only damage files owned by that user.
2. No audit trail. With sudo, every command run is recorded to a log file like /var/log/auth.log. If your system is hacked, this log is the first piece of evidence. Logging in directly as root leaves almost no trace that can be linked to an individual.
3. No mental barrier. Forcing you to type sudo in front of a dangerous command provides a "reflection second" — a chance to think twice before pressing Enter.

This principle is known as least privilege: every user (including applications) should have the minimum access rights needed to do their job. Sudo is the most common implementation of this principle in Linux.

#su - vs sudo: Two Ways, Two Different Philosophies

Many beginners think su and sudo are the same. In fact, they are opposite philosophies.

su - (switch user) replaces your identity entirely. su - without an argument means "switch to the root user with a complete environment" (the - makes a login-like root shell, complete with root's PATH and environment variables). After running it, every subsequent command runs as root until you type exit. It's like giving someone the master key to an entire building and letting them roam around.

sudo (superuser do) only executes one specific command with root rights, then returns to your original identity. sudo apt update means "run apt update as root, only this command". You stay logged in as a regular user; no root session is opened.

Let's see the comparison directly:

# With su -
$ whoami
arman
$ su -
Password:
# whoami
root
# exit
logout
$
 
# With sudo — still a regular user, only the command is root
$ whoami
arman
$ sudo whoami
root
$ whoami
arman

It's also worth noting: su - requires the root password, while sudo requires the password of the user running it (your own password). This is a crucial difference — with sudo, the root password never needs to be shared with anyone.

#The Anatomy of the sudoers Configuration

When you type sudo <command>, the system asks: "Does this user have the right to execute commands as root or not?" The answer is in a config file called /etc/sudoers. This file is the only source of truth for sudo rules.

The basic sudoers rule structure has four columns: the user/group being granted rights, the host where the rule applies, the target user (run as), and the commands allowed to run. The most common example:

root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
%admin  ALL=(ALL:ALL) ALL

Reading the line %sudo ALL=(ALL:ALL) ALL:

Note that the % character denotes a group. Without %, it's treated as a user name. So sudo ALL=(ALL:ALL) ALL grants full rights to a user named sudo, not a group.

One important thing: never edit /etc/sudoers directly with a regular editor. Instead, use visudo:

sudo visudo

visudo does two vital things: it locks the file so two editors can't overwrite each other, and it validates the syntax before saving. If there's a syntax error, visudo refuses to save and gives you a chance to fix it — this is what prevents you from locking yourself out of sudo access.

The /etc/sudoers.d/ directory allows splitting rules per-application or per-user. Files in this directory are automatically included by /etc/sudoers (the #includedir /etc/sudoers.d line), so you can place specific service configuration there without cluttering the main file:

deploy ALL=(root) /usr/bin/systemctl restart nginx, \
                     /usr/bin/systemctl reload nginx

#Granting Sudo Rights to a User or Group

The best way to give administrator access to many people isn't one-by-one per user, but through a group. This is exactly like an office access badge: rather than giving keys to each employee and retrieving them one by one when they leave, it's easier to manage group membership. On Debian/Ubuntu the group is named sudo; on RHEL/Fedora it's named wheel.

To add a user to the sudo group, we use usermod -aG (append to the group, don't forget -a!):

sudo usermod -aG sudo arman
# Verify group membership
id arman

After the command above, user arman can immediately use sudo — but the running login session doesn't recognize it yet. The user must logout and log back in (or run newgrp sudo) for the group membership to take effect in that session.

On the RHEL family, the command is the same except the group name is wheel:

sudo usermod -aG wheel arman
id arman

#The NOPASSWD Option for Automation

The downside of sudo is that it asks for a password every time. For automation scripts (for example a backup job running at midnight via cron, or provisioning tools like Ansible), entering an interactive password is impossible. The solution is the NOPASSWD option — certain commands may be run without a password:

backup ALL=(root) NOPASSWD: /usr/local/bin/backup-db.sh

The rule above reads: user backup may run /usr/local/bin/backup-db.sh as root without being asked for a password — and only that command. This is the correct least privilege for automation pattern.

It's worth understanding that NOPASSWD makes certain commands valuable automation gateways — but also targets. A script allowed to run without a password must be placed in a path only root can write, and its contents must be reviewed, because executing that script is the only "key" a potential attacker holds.

#Practice: Adding a User to the Sudo Group & Granting sudoedit Rights

Let's chain all the concepts above in one real scenario: you manage a VPS, want to give a new user reza full administrative access, then restrict user deploy to only edit Nginx config files — not all files.

# 1. Create user reza with a home dir & bash shell
sudo useradd -m -s /bin/bash reza
sudo passwd reza
 
# 2. Give reza full sudo access via the group
sudo usermod -aG sudo reza
 
# 3. Create a special rule for user deploy (only Nginx sudoedit)
sudo visudo -f /etc/sudoers.d/deploy-nginx

Contents of the /etc/sudoers.d/deploy-nginx file:

deploy ALL=(root) sudoedit /etc/nginx/nginx.conf, \
                          /etc/nginx/sites-available/*

With the rule above, user deploy can run sudoedit /etc/nginx/nginx.conf to edit Nginx files through a safe temporary copy — but cannot use sudo cat to read, sudo rm to delete, or sudo systemctl to restart the service. When Nginx needs a reload, they have to ask an admin. That's what precise control means.

Important note on sudoedit: unlike sudo nano file, sudoedit always validates that the file being edited is in the allowed list before opening the editor — which is why it's far safer to share with many users. sudo vim file doesn't check the allowed list the same way.

To verify the rule applies, the user in question can run sudo -l to see their list of rights:

$ sudo -l
Matching Defaults entries for reza:
    env_reset, mail_badpass, secure_path=...
User reza may run the following commands on this host:
    (ALL : ALL) ALL

#Common Mistakes in Managing Sudo

The most dangerous mistake in this episode is editing /etc/sudoers with a regular editor without visudo. One wrong character — for example %sudo ALL=(ALL:ALL) ALL missing one of the ALLs — makes the syntax invalid. Because sudo validates this file every time it runs, the system will refuse all sudo commands: you're locked out of admin access. If the file was saved before validation, this is the classic "lockout" scenario.

There are two recovery paths: from a physical/virtual machine console (logging in as root via su - from a TTY), or booting with init=/bin/bash in GRUB. In cloud environments, use the VNC console from the provider's panel. The key lesson: always use visudo, and keep a backup file before changing sudoers.

There's also a small trick often used that's worth understanding: sudo !!. The !! is history expansion — Bash replaces it with the last command. So when you type apt update without sudo and hit permission denied, just type sudo !! to rerun the last command with root rights. Efficient, but be careful: !! takes the last command in history, not "the one that failed" — if the last command has already changed, that's what will be executed.

#Conclusion

In this episode 10 we've closed the loop on Linux access security: understanding why uncontrolled root is dangerous, distinguishing the philosophies of su - (full identity switch) vs sudo (specific command execution), reading and managing /etc/sudoers with visudo, granting rights through the sudo/wheel groups, restricting automation with narrow NOPASSWD, and chaining it all in a precise sudoedit practice. The principle to take home: give the least rights possible, audit every command, and never touch sudoers without visudo.

With admin rights in hand, you're now ready to do the most fundamental thing an administrator does: install software. In the next episode 11 we'll discuss package management across distros — apt for Debian/Ubuntu, dnf for the RHEL family, pacman for Arch, plus universal formats like snap, flatpak, and AppImage. That's where the difference in "how you get software" between distros really becomes felt. See you in the next episode!