sudo command gives a user superuser or root powers. No doubt you gave them the “with great power comes great responsibility” speech. Here’s how to check if they listened or not.
The sudo Command
sudo command stands for “substitute user do.” It lets an authorized person execute a command as though they were another user. It can take command line parameters, one of which is the name of the user you wish to have the command executed as. The most common way
sudo is used is to omit the command line options and use the default action. This effectively executes the command as the root user.
sudo in this way requires special permission. Only the privileged can use
sudo. When you install a modern Linux distribution, you’re prompted to set up a root password that you can use with
sudo. Permission to do so is granted to the regular user that you create during installation. This is the preferred way to handle access to the capabilities of the root user. The old way was to create a root user and log in as them in order to administer your system.
This was a dangerous scenario. It was easy to forget to—or be too lazy to—log out and back in as your regular user when you no longer required root privileges. Any mistakes you made in the terminal window as root would be executed, no matter how drastic. Stuff that would be blocked by the shell if a regular user tried to do them would run without question when root requested them. Using the root account instead of a regular account is also a security risk.
sudo focuses the mind. You’re entering the same dangerous waters, but you’re consciously choosing to do so, and hopefully taking great care. You only invoke your superuser status when you need to do something that needs them.
If you open root access up to other users you want to know that they’re taking just as much care with them as you do. You don’t want them running commands recklessly or speculatively. The health and well-being of your Linux installation depend on privileged users behaving respectfully and responsibly.
Here are several ways to monitor their root usage.
The auth.log File
Some distributions maintain an authentication log, in a file called “auth.log.” With the advent and rapid uptake of
systemd, the need for the “auth.log” file was removed. The
systemd-journal daemon consolidates the system logs into a then-new binary format and
journalctl provides a way for you to examine or interrogate the logs.
If you do have an “auth.log” file on your Linux computer, it’ll probably be in the “/var/log/” directory, although on some distributions the filename and path are “/var/log/audit/audit.log.”
You can open the file in
less like this. Remember to adjust the path and filename to suit your distribution, and be prepared in case your Linux doesn’t even create an authentication file.
This command worked on Ubuntu 22.04.
The logfile is opened, and you can scroll through the file or use the search facilities built into less to search for “sudo.”
Even using the search facilities of
less, it can take some time to locate the
sudo entries you’re interested in.
Let’s say we want to see what a user called
mary has used
sudo for. We can search the logfile with
grep for lines with “sudo” in them, and then pipe the output through
grep again and look for lines with “mary” in them.
sudo before grep and before the logfile name.
sudo grep sudo /var/log/auth.log | grep "mary"
This gives us lines that have “sudo” and “mary” in them.
We can see that the user
mary was given
sudo privileges at 15:25, and at 15:27 she’s opening the
fstab file in an editor. That’s the type of activity that definitely warrants a deeper dive, starting with a chat with the user.
The preferred method on
systmd-based Linux distributions is to use the
journalctl command to review system logs.
If we pass the name of a program to
journalctl it will search the log files for entries that contain references to that program. Because
sudo is a binary located at “/usr/bin/sudo” we can pass that to
-e (pager end) option tells
journalctl to open the default file pager. Usually this will be
less. The display is automatically scrolled to the bottom to show the most recent entries.
sudo journalctl -e /usr/bin/sudo
The log entries that feature
sudo are listed in less.
Use the “RightArrow” key to scroll to the right to see the command that was used with each of the invocations of
sudo. (Or stretch your terminal window so that it is wider.)
And because the output is displayed in
less, you can search for text such as command names, user names, and time stamps.
Using the GNOME Logs Utility
Graphical desktop environments usually include a means of reviewing logs. We’ll look at the GNOME logs utility. To access the logs utility, press the “Super” key to the left of the “Spacebar.”
Type “logs” in the search field. The “Logs” icon appears.
Click the icon to launch the “Logs” application.
Clicking on the categories in the sidebar will filter the log messages by message type. To make more granular selections, click the “All” category in the sidebar, then click the magnifying glass icon on the toolbar. Enter some search text. We’re going to search for “sudo.”
The list of events is filtered to display only those events that relate to the
sudo command. A small gray block at the end of each line contains the number of entries in that event session. Click a line to expand it.
We clicked the top line to see the details of the 24 entries in that session.
With a little scrolling, we can see the same events that we saw when we used the
journalctl command. User
mary‘s unexplained editing session on the
fstab file is quickly found. We could have searched for “mary”, but that would include entries other than her use of
Not Everyone Needs root Access
Where there’s a genuine, sensible requirement, giving
sudo privileges to other users can make sense. Likewise, it only makes sense to check on their use—or abuse—of these powers, especially just after they’ve been given them.