Learn › RHCSA (EX200) › Users and Groups
visudo - a hands-on Linux lab on a real virtual machine.
Grant administrative rights safely. Never edit /etc/sudoers with a raw editor: use visudo, which syntax-checks on save, or drop a rule file into /etc/sudoers.d/ at mode 0440. Check the whole policy with visudo -c, grant a whole group with a %group rule like %devs ALL=(ALL) ALL, use the built-in wheel admin group, add NOPASSWD: to skip the password prompt, and audit what any user may run with sudo -l -U NAME. Serves EX200 users-groups: configure superuser access.
A new engineer needs to run admin commands, so you open /etc/sudoers in a plain text editor, add a line, and save. Somewhere in that line you fat-finger a keyword: ALL becomes ALLL. You save and quit. The next time anyone runs sudo, it refuses, because the file will not parse. Every command that needed elevated rights is now blocked, including the sudo you would use to fix the file. The whole machine's admin access is jammed by a single stray letter.
This is why you never edit /etc/sudoers with a raw editor. There is a tool built exactly to prevent this, and there is a safer place to put your rules entirely. This lesson teaches both, plus how to grant rights to a whole group, skip the password prompt when you mean to, and audit exactly what any user is allowed to run. Configuring superuser access safely is a graded EX200 objective, and getting it wrong on the exam machine is the same jam as getting it wrong at work.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2). A few values, like the exact UID and GID numbers behind the alice and devs names, depend on what already exists on the machine, so treat those as illustrative. What is stable everywhere is the SHAPE: visudo -c reports each file parsed OK, a %group line grants a group, and sudo -l -U lists what a named user may run.
sudo lets an ordinary user run a single command with the powers of another user, almost always root, after proving who they are with their own password. It is the controlled doorway between everyday accounts and full administrative power. Instead of handing out the root password, you write rules that say which users may run which commands, and sudo enforces them.
Those rules live in one place: the sudoers policy. The main file is /etc/sudoers, and it has a strict grammar. Think of it like the guest list at a locked door: the door only opens for names on the list, and if the list itself is written in a garbled hand nobody gets in at all. That fragility is the whole reason for the tools in this lesson.
visudo is the safe way to edit the sudoers policy. It opens the file in an editor exactly like vi or nano would, but with one critical difference: when you save, it checks the grammar first. If the file has a syntax error, visudo refuses to install the broken version and offers to let you fix it. A raw editor has no such check, which is how a single typo locks out every admin on the box.
There is a second safety habit that pairs with it. Rather than touching the big /etc/sudoers file at all, you drop your own small rule files into the directory /etc/sudoers.d/. The main file already includes everything in that directory, so a file there is live policy. This keeps your changes isolated, easy to read, and easy to remove: one rule per file, named for what it does.
Before you change anything, learn the command that tells you the whole policy is healthy. visudo -c runs the same syntax check visudo does on save, but on demand and without opening an editor. The -c stands for check. It walks /etc/sudoers and every file in /etc/sudoers.d/ and reports each one as parsed OK, or names the file and line where the grammar breaks.
Before you run it, know what success looks like: one parsed OK line per file, no error. Validate the policy:
visudo -c
prompt: [root@servera ~]# answer: visudo -c output: /etc/sudoers: parsed OK /etc/sudoers.d/devs: parsed OK hint: The checker is visudo with the -c (check) flag, nothing else: visudo -c
Each line names a file and reports parsed OK, meaning the grammar is valid and sudo will honor it. The first line is the main /etc/sudoers; the second is a drop-in file /etc/sudoers.d/devs that we are about to create. If any file were broken, visudo -c would print the filename and the line number of the error instead of parsed OK, and you would know exactly where to look before that error ever reached a live sudo call. This is the command to run any time you have hand-edited policy and want proof it is safe.
You rarely grant rights to one person at a time. You grant them to a group, then add people to the group. In a sudoers rule, a name with a % in front means a group instead of a user. So %devs means every member of the group devs.
The safe way to add this rule is a drop-in file. Write one line into /etc/sudoers.d/devs, then lock its permissions to 0440, which is what sudo requires (more on that in a moment). The rule %devs ALL=(ALL) ALL reads: members of devs, on ALL hosts, may run commands as (ALL) users, and may run ALL commands. Create the group rule:
echo "%devs ALL=(ALL) ALL" > /etc/sudoers.d/devs ; chmod 440 /etc/sudoers.d/devs
prompt: [root@servera ~]# answer: echo "%devs ALL=(ALL) ALL" > /etc/sudoers.d/devs ; chmod 440 /etc/sudoers.d/devs output: hint: Redirect the %devs rule into a file under /etc/sudoers.d/, then chmod 440 it.
No output means both commands succeeded. The echo ... > /etc/sudoers.d/devs wrote a single line of policy into its own file, and chmod 440 set the permissions to read-only for owner and group, with nothing for others. Reading the rule left to right: %devs is the group, the first ALL is which hosts it applies to, (ALL) is which users a member may become, and the final ALL is which commands they may run. Add any user to the devs group and they inherit full admin rights through this one line, with no edit to the main sudoers file at all.
Sudo ignores a drop-in file that has the wrong permissions or owner, silently. A file in /etc/sudoers.d/ must be mode 0440 (owner root, group root) or sudo skips it as untrusted, and your rule simply does nothing with no error to tell you why. If a group rule you wrote is not taking effect, check the mode first with ls -l /etc/sudoers.d/. Two other traps: a filename containing a dot or ending in ~ is also ignored, so name drop-ins plainly like devs, not devs.conf or devs.bak.
Once rules exist across a main file and several drop-ins, no single file tells you what a given person can actually do. The command that answers that is sudo -l -U NAME. The -l means list the permissions, and -U NAME means for the named user, not yourself. It reads the whole policy the way sudo itself does and prints the effective rights for that one account.
Before you run it, predict the result: alice is in the devs group, and that group rule grants ALL commands, so she should be allowed to run anything. Audit her rights:
sudo -l -U alice
prompt: [root@servera ~]# answer: sudo -l -U alice output: User alice may run the following commands on servera: (ALL) ALL hint: List a user's rights with sudo -l, then -U and the username: sudo -l -U alice
The output states plainly that alice may run, on host servera, (ALL) ALL: as any user, any command. That is the group rule you wrote resolving through her membership in devs. The (ALL) in parentheses is the set of users she may act as, and the ALL after it is the set of commands. Run this to prove a grant worked, or to answer an exam task that says confirm this user can run commands as root. It reads the live policy, so it reflects drop-ins and group memberships together, exactly as sudo does at runtime.
The exact UID and GID numbers behind alice and devs are assigned when those accounts and groups are created, so on your machine they may differ from any example. What does not change is the shape of this output: the may run the following commands on <host> header, followed by one indented (users) commands line per rule that applies to that user. Read the (ALL) ALL line; the numbers behind the names do not matter here.
RHEL ships with a group already wired for admins: wheel. The default /etc/sudoers contains a line, %wheel ALL=(ALL) ALL, so adding any user to wheel grants them full sudo immediately, with no new rule to write. On the exam, if a task just says give this user administrative access, adding them to wheel with usermod -aG wheel NAME is often the shortest correct path. Confirm the built-in rule is there:
grep ^%wheel /etc/sudoers
prompt: [root@servera ~]# answer: grep ^%wheel /etc/sudoers output: %wheel ALL=(ALL) ALL hint: Search the sudoers file for a line starting with %wheel: grep ^%wheel /etc/sudoers
The line %wheel ALL=(ALL) ALL is the same grammar as your devs rule, shipped by default: members of the wheel group may run any command as any user. This is why wheel is the canonical admin group on RHEL. There is one more modifier worth knowing: put NOPASSWD: right before the command field and sudo stops asking for a password for that rule. So %devs ALL=(ALL) NOPASSWD: ALL lets the devs group run everything without a prompt. Use it deliberately, because it removes the one check that stops a hijacked shell from running root commands unchallenged.
Scaffolding off. No command is printed this time. You have every piece you need.
You have just added the user alice to a group that carries a sudo rule. Before you hand the machine back, a task tells you to confirm exactly what alice is now allowed to run, reading the effective policy the way sudo itself sees it, not by opening files and piecing rules together by hand. Which single command, given her username, prints the list of commands she may run and as whom?
prompt: [root@servera ~]# answer: sudo -l -U alice output: User alice may run the following commands on servera: (ALL) ALL hint: It is the list flag plus the for-user flag: sudo -l -U, then the username alice.
sudo -l -U alice reads the entire live policy, main file and every drop-in and group membership, and prints that alice may run (ALL) ALL on servera. That is the audit step for every superuser-access task on the exam. Opening the files by hand would eventually get you the same answer. But only sudo -l -U NAME resolves them all into the effective rights, in one line, the way sudo does at runtime. When a task says confirm this user can run commands as root, this is the command that proves it.
You earned this cheat sheet. Every row is a form you just ran or built:
The one thing to burn in for the exam: never edit /etc/sudoers directly. Use visudo, or drop a 0440 rule file into /etc/sudoers.d/. A % prefix means a group, NOPASSWD: skips the prompt, and sudo -l -U NAME audits what a user may run.
When you do open the policy to edit it, reach for visudo every single time, even for a one-line change. It is the difference between a typo you fix in the editor and a typo that locks admin access off the whole machine. Pair it with the drop-in habit: for anything new, write a small file in /etc/sudoers.d/ instead of touching the main file, so a mistake is contained to one removable file.
The practice terminal has walked you through the whole loop. visudo -c to prove the policy is healthy, a %devs drop-in at mode 0440 to grant a whole group, sudo -l -U to audit exactly what a user may run, and the built-in wheel group and NOPASSWD: modifier for the common shortcuts. Every one of those you typed yourself.
Operation Roster is the users-groups mission where you run these against a real RHEL 10 machine. A full VM boots for you, with real accounts and groups to build and wire together. The mission hands you objectives that use exactly what you practiced here, and more from this module: create users, set their groups, and grant a group administrative access through sudo the safe way. Verify a user's rights with sudo -l -U, confirm the policy parses with visudo -c, and never touch /etc/sudoers with a raw editor.
One difference from this lesson: the mission shows no commands. You read the objective, recall the visudo and drop-in and sudo -l -U forms, and type them. That recall is what makes it stick on exam day.
Finish the other users-groups lessons, then take on Operation Roster and grant admin rights on a real machine.
Practice sudo Configuration in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.