Skip to main content
When a Linux shell replies “permission denied” after you try to install software, restart a service, or edit a system file, it’s not a bug — it’s privilege enforcement working as intended. This guide explains how privilege and privilege escalation work on Red Hat Enterprise Linux (RHEL), how to safely grant administrative rights using sudo, and why assigning the minimum necessary privileges (least privilege) is critical for security and auditability. Analogy: regular users are employees with keys to their office and shared areas. The superuser (root) is the building administrator with a master key who can change locks and modify the building. You wouldn’t hand out the master key to everyone — instead, delegate only the keys needed for specific tasks. sudo is the mechanism that lets you do exactly that: grant specific administrative commands, optionally require a password, and record who ran what.
A dark-themed infographic titled "SuperUser Access" comparing two roles. The left side shows Regular Users (employees) with access to their office and shared areas, while the right shows Super Users (root/building administrators) with access to any room and permissions like changing locks and modifying the building.
Which users can run sudo, and which commands they may run, are defined in /etc/sudoers and in files under /etc/sudoers.d/. Because a malformed sudoers file can break sudo for everyone, always edit these files with visudo, which validates syntax before saving.
Always use visudo (or visudo -f /etc/sudoers.d/<file>) to edit /etc/sudoers or files under /etc/sudoers.d/. visudo checks syntax and helps prevent configuration errors that could lock out administrative access.

​
Sudoers entry structure

A sudoers entry consists of:
  • Subject: a user or a group (groups use a leading %)
  • Host: which host(s) the rule applies to (often ALL)
  • Run-as specification: who the command may be run as, e.g. (ALL) or (root)
  • Command list: the allowed commands, or exclusions prefixed with !
Examples of common sudoers lines:
An infographic titled "Delegating Administrative Privileges" comparing the risk of giving away the root key with the solution of using sudo. It shows root key → uncontrolled access versus using a 'useradd' key and /etc/sudoers → controlled and logged access.

​
Practical demo: granular sudo rules

In this demo we use four pre-created users: Alice, Bob, Carol, and Dave. Dave is a member of the opsadmins group. First, verify the users and groups:
Create a sudoers file for the demo using visudo -f:
Insert the following rules into /etc/sudoers.d/demo-sudo to demonstrate common delegation patterns:
Save and exit. Now test each user’s delegated privileges.

​
1) Alice — full sudo access (password required)

Both commands succeed because Alice is permitted to run any command via sudo.

​
2) Bob — limited to useradd and userdel

Bob may create and delete accounts but cannot run other user-management commands like usermod because they are not listed.

​
3) Carol — all commands except userdel

Carol can perform most administrative tasks but an explicit deny prevents her from deleting users.

​
4) Dave — member of opsadmins, passwordless full access

To inspect a user’s effective sudo privileges, use sudo -l:

​
Best practices

  • Follow the principle of least privilege: grant only the commands required for a task.
  • Use group aliases and command aliases in sudoers to simplify complex policies.
  • Prefer sudo over sharing the root password: sudo provides per-user accountability and logs commands to the system audit logs.
  • Test sudoers changes with visudo and validate behavior with sudo -l for each user.
Further reading and references: This demo demonstrates how to delegate administrative capabilities safely without handing out the root password. Carefully crafted sudoers entries provide secure, auditable delegation that fits real-world operational needs.

Watch Video