sudo and root access: visudo, sudoers.d and sudo-rs

Steps 1 to 7 run on rocky01, logged in as student. Step 8 repeats the rule on ubu01 and step 9 looks at what sudo-rs does differently. Keep a second terminal open with sudo -i running while you work, so that if you lock yourself out of sudo you still have a root shell to fix it.

1See what sudo allows you

Run this:

whoami
sudo whoami
sudo -l | tail -n 2

You should see something like this:

student
[sudo] password for student:
root
User student may run the following commands on rocky01:
    (ALL) ALL

sudo -l lists your own rights, and the first lines (cut here with tail) show the Defaults that apply. student gets (ALL) ALL through the wheel group. sudo asked for student’s own password, not root’s.

✅ Checkpoint: sudo whoami prints root and sudo -l shows (ALL) ALL.

2Read the default rules

Run this:

sudo grep -E '^(root|%|@include|#include)' /etc/sudoers

You should see something like this:

root	ALL=(ALL) 	ALL
%wheel	ALL=(ALL)	ALL
#includedir /etc/sudoers.d

The wheel line is why student has full rights. The last line pulls in every file in /etc/sudoers.d, and despite the # it is not a comment: #includedir is the old spelling of @includedir, which newer files (and Ubuntu) use. Your file may show either one.

✅ Checkpoint: You can point to the line that gives wheel its rights and the line that reads /etc/sudoers.d.

3Compare su and sudo

Run this, typing the root password you set in the installer:

su -
whoami; pwd
exit

You should see something like this:

Password:
root
/root
logout

su - gave you a full root login shell with root’s home and environment, and the log only says that student became root. That’s why teams keep the root password in a vault for emergencies (Lesson 70 uses it on the console) and use sudo for daily work. The same command on ubu01 fails with su: Authentication failure, because Ubuntu’s root has no password at all.

✅ Checkpoint: You got a root prompt with su and left it with exit.

4Write the webteam rule with visudo

Run this:

sudo visudo -f /etc/sudoers.d/webteam

In the editor, paste this whole block, then save and quit (:wq in vi):

# /etc/sudoers.d/webteam  (SaatVedha Linux course, Lesson 16)
# webteam may check, restart and reload nginx and read its logs. Nothing else.
Cmnd_Alias WEB_SVC  = /usr/bin/systemctl status nginx --no-pager, \
                      /usr/bin/systemctl restart nginx, \
                      /usr/bin/systemctl reload nginx
Cmnd_Alias WEB_LOGS = /usr/bin/journalctl -u nginx --no-pager -n 100, \
                      /usr/bin/journalctl -u nginx --no-pager --since today
%webteam ALL=(root) WEB_SVC, WEB_LOGS

Then set the file mode and check the whole policy:

sudo chmod 0440 /etc/sudoers.d/webteam
sudo visudo -c
sudo ls -l /etc/sudoers.d/webteam

You should see something like this:

/etc/sudoers: parsed OK
/etc/sudoers.d/webteam: parsed OK
-r--r-----. 1 root root 507 Oct 27 11:48 /etc/sudoers.d/webteam

visudo edits a temporary copy, checks the syntax and only then saves. A new file it creates can come out as mode 640, while sudo expects 440 (read-only for root and group root) and visudo -c reports “bad permissions” for anything else, so set it yourself. The two aliases group the allowed commands, and the last line grants them to the webteam group as root.

Every command has its full path and exact arguments, and --no-pager is there on purpose: without it systemctl and journalctl can open less, and a pager is one key away from a shell.

✅ Checkpoint: visudo -c says parsed OK for both files and ls shows mode 440 (-r--r-----).

5Check what priya can do, without logging in as her

Run this:

sudo -l -U priya

You should see something like this (the Matching Defaults lines are cut here):

User priya may run the following commands on rocky01:
    (root) /usr/bin/systemctl status nginx --no-pager, /usr/bin/systemctl
        restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/journalctl -u
        nginx --no-pager -n 100, /usr/bin/journalctl -u nginx --no-pager
        --since today

-U lets an admin read anyone’s rights. Do this after every sudo change, because it shows how sudo understood your file, which isn’t always what you meant. arjun gets the same list through the same group.

✅ Checkpoint: priya’s list shows the three systemctl commands and the two journalctl commands, and nothing else.

6Test as priya

Switch to priya (her password from Lesson 15), then run:

su - priya
sudo systemctl status nginx --no-pager
sudo systemctl status sshd --no-pager
sudo cat /etc/shadow
exit

You should see something like this:

[sudo] password for priya:
Unit nginx.service could not be found.
Sorry, user priya is not allowed to execute '/usr/bin/systemctl status sshd --no-pager' as root on rocky01.
Sorry, user priya is not allowed to execute '/usr/bin/cat /etc/shadow' as root on rocky01.

The first command was allowed (Nginx isn’t installed until Lesson 56, so systemctl has nothing to show, which is fine). The same command for sshd was refused because the argument is different, and reading /etc/shadow was refused. Allowed means the exact command line in the rule, not “anything starting with systemctl”.

✅ Checkpoint: One command was allowed and two were refused with “is not allowed to execute”.

7Find priya’s commands in the logs

Back as student, run this:

sudo journalctl -t sudo --since "10 min ago" --no-pager | grep priya
sudo grep 'priya :' /var/log/secure | tail -n 2

You should see something like this:

Oct 27 11:52:10 rocky01 sudo[2304]:    priya : TTY=pts/1 ; PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/systemctl status nginx --no-pager
Oct 27 11:52:10 rocky01 sudo[2304]: pam_unix(sudo:session): session opened for user root(uid=0) by priya(uid=1001)
Oct 27 11:52:31 rocky01 sudo[2311]:    priya : command not allowed ; TTY=pts/1 ; PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/systemctl status sshd --no-pager
Oct 27 11:52:44 rocky01 sudo[2318]:    priya : command not allowed ; TTY=pts/1 ; PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
Oct 27 11:52:31 rocky01 sudo[2311]:    priya : command not allowed ; TTY=pts/1 ; PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/systemctl status sshd --no-pager
Oct 27 11:52:44 rocky01 sudo[2318]:    priya : command not allowed ; TTY=pts/1 ; PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow

Every attempt is there with the user, terminal, folder and the full command, and refused ones say “command not allowed”. The journal is the reliable place on both distributions. /var/log/secure exists when rsyslog is installed, which it is on a standard Rocky server; if it’s missing on yours, use the journal.

✅ Checkpoint: You can see the allowed status command and the two refused attempts, all under priya’s name.

8Same rule on ubu01, with sudo-rs

On ubu01, as student, run this (set priya’s password when asked, then paste the same rule from step 4 into visudo):

sudo --version
sudo passwd priya
sudo visudo -f /etc/sudoers.d/webteam
sudo chmod 0440 /etc/sudoers.d/webteam
sudo visudo -c
sudo -l -U priya

You should see something like this:

sudo-rs 0.2.13-0ubuntu1.2
[sudo: authenticate] Password: *********
New password:
Retype new password:
passwd: password updated successfully
/etc/sudoers: parsed OK
User priya may run the following commands on ubu01:
    (root) /usr/bin/systemctl status nginx --no-pager, /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/journalctl -u nginx --no-pager -n 100, /usr/bin/journalctl -u nginx --no-pager --since today

The rule file is identical and it works the same way. The small differences are sudo-rs ones: the password prompt shows asterisks, visudo -c prints only the main file (it still checks the included files and names any file with an error), and sudo -l prints one long line.

Now test as priya and read the log:

su - priya
sudo cat /etc/shadow
sudo systemctl status nginx --no-pager
exit
sudo grep 'priya :' /var/log/auth.log | tail -n 1

You should see something like this:

sudo: I'm sorry priya. I'm afraid I can't do that
[sudo: authenticate] Password: *********
Unit nginx.service could not be found.
2026-10-27T12:05:44.118302+05:30 ubu01 sudo: priya : TTY=/dev/pts/1 ; PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/systemctl status nginx --no-pager

sudo-rs refused the shadow file before asking for a password, with a message borrowed from a famous film computer. In our tests sudo-rs 0.2.13 logged allowed commands and failed passwords, but not a refused command like the cat above, so don’t build an alert on “command not allowed” lines on Ubuntu 26.04 without testing it on your version. The auth.log line uses the RFC 3339 timestamp from Lesson 14, and the TTY is written as /dev/pts/1.

✅ Checkpoint: On ubu01, priya can run the status command and is refused for /etc/shadow.

9Know what sudo-rs does differently

On ubu01, run this:

update-alternatives --display sudo | head -n 3
ls -l /usr/bin/sudo.ws /usr/sbin/visudo.ws

You should see something like this:

sudo - auto mode
  link best version is /usr/lib/cargo/bin/sudo
  link currently points to /usr/lib/cargo/bin/sudo
-rwsr-xr-x 1 root root 282080 Mar 13  2026 /usr/bin/sudo.ws
-rwxr-xr-x 1 root root 199456 Mar 13  2026 /usr/sbin/visudo.ws

sudo, sudoedit and visudo are alternatives links pointing at sudo-rs, and the classic sudo is still installed as sudo.ws. Most rules written for classic sudo work unchanged, but these are the differences that show up at work:

If an application needs classic sudo, sudo update-alternatives --set sudo /usr/bin/sudo.ws switches back and sudo update-alternatives --auto sudo returns to sudo-rs. Canonical recommends staying on sudo-rs, so treat this as a temporary workaround and write it in the change record.

✅ Checkpoint: You can name two things that work in classic sudo but not in sudo-rs, and how to switch between them.