sudo and Root Permissions

We’ve all heard (the oversimplification) that everything in Linux is a file. In truth, virtually everything in the operating system from processes, files, directories, sockets, and pipes talk to the kernel through a file descriptor. So although everything isn’t a file, most operating system objects are handled as though they were. Where possible, the design of Linux and Unix-like operating systems adhere to this principle.

The concept of “everything is a file” is far-reaching in Linux. It’s easy to see then, how file permissions in Linux became one of the mainstays of user privileges and rights. If you own a file or directory (a special kind of file), you can do what you like with it, including editing, renaming, moving, and deleting it. You can also set the permissions on the file so that other users or groups of users can read, modify, or execute the file. Everyone is governed by these permissions.

Everyone that is, apart from the superuser, known as root. The root account is a specially privileged account. It is not bound by the permissions on any of the objects in the operating system. The root user can do anything to anything and, pretty much, at any time.

Of course, anyone with access to root’s password can do the same. They could wreak havoc either maliciously or accidentally. In fact, the root user can wreak havoc by making a mistake too. No one is infallible. It’s dangerous stuff.

This is why it is now considered best practice to not log in as root at all. Log in with a regular user account and use sudo to elevate your privileges for the short duration you need them. Often that is just to issue a single command.

RELATED: What Does “Everything Is a File” Mean in Linux?

The sudoers List

sudo was already installed on the Ubuntu 18.04.3, Manjaro 18.1.0, and Fedora 31 computers used to research this article. This is not a surprise. sudo has been around since the early 1980s and has become the standard means of superuser operation for almost all distributions.

When you install a modern distro, the user you create during the install is added to a list of users called sudoers. These are the users who can use the sudo command. Because you have sudo powers, you can use them to add other users to the list of sudoers.

Of course, it is reckless to hand out full superuser status willy-nilly, or to anyone who has only a partial or specific need. The sudoers list allows you to specify which commands the various users are allowed to use sudo with. That way, you don’t give them the keys to the kingdom, but they can still accomplish what they need to do.

Running a Command as Another User

Originally, it was called “superuser do”, because you could do things as the superuser. Its scope has been widened now, and you can use sudo to execute a command as though you were any user. It has been renamed to reflect that new functionality. It is now called “substitute user do.”

To use sudo to run a command as another user, we need to use the -u (user) option. Here, we’re going run the whoami command as the user mary. If you use the sudo command without the -u option, you’ll run the command as root.

And of course, because you’re using sudo you’ll be prompted for your password.

The response from whoami tells us that the user account running the command is mary.

You can use the sudo command to log in as another user without knowing their password. You’ll be prompted for your own password. We need to use the -i (login) option.

You are logged in as mary. The “.bashrc”, “.bash_aliases”, and “.profile” files for the mary user account are processed exactly as if the owner of the mary user account had logged in themselves.

The command prompt changes to reflect this is a session for user account mary. The pwdcommand reprots that you are now in  mary’s home directory. whoami tells us you are using user account mary. The files in the directory belong to the mary user account. The exit command returns you to your normal user account session.

Editing the sudoers File

To add users to the list of people who can use sudo , you need to edit the sudoers file. It is vitally important that you only ever do so using the visudo command. The visudo command prevents multiple people from trying to edit the sudoers file at once. It also performs syntax checking and parsing on the file contents as you save them.

If your edits don’t pass the tests, the file isn’t blindly saved. You get options. You can cancel and abandon the changes,  go back and edit the changes again, or force the incorrect edits to be saved. The last option is a seriously bad idea. Don’t be tempted to do that. You can find yourself in a situation where everyone is accidentally locked out of using sudo.

Although you start the editing process using the visudo command, visudo isn’t an editor. It calls one of your existing editors to perform the file edits. On Manjaro and Ubuntu, the visudo command launched the simple editor nano. On Fedora, visudo launched the more capable—but less intuitive—vim.

RELATED: How to Exit the Vi or Vim Editor

If you’d prefer to use nano on Fedora, you can do so easily. First, install nano:

sudo dnf install nano

And then visudo had to be invoked with this command:

That looks like a good candidate for an alias. The nano editor is opened with the sudoers file loaded in it.

Adding Users to the sudo Group

Use visudo to open the sudoers file. Either use this command or the one described above to specify the editor of your choice:

Scroll through the sudoers file until you see the definition of the %sudo entry.

The percentage sign indicates that this is a group definition and not a user definition. On some distributions, the %sudo line has a hash # at the start of the line. This makes the line a comment. If this is the case, remove the hash and save the file.

The %sudo line breaks down like this:

%sudo: The name of the group. ALL=: This rule applies to all hosts on this network. (ALL:ALL): members of this group can run commands as all users and all groups. All: members of this group can run all commands.

To reword that slightly, members of this group can run any command, as any user or any group, on this computer or on any other host in this network. So a simple way to give someone root privileges and the ability to use sudo, is to add them to the sudo group.

We’ve got two users, Tom and Mary, with user accounts tom and mary respectively. We’ll add user account tom to the sudo group with the usermod command. The -G (groups) option specifies the group we’re going to add the tom account to. The -a (append) option adds this group to the list of groups the user account tom is already in. Without this option, the user account tom would be placed in the new group but removed from any other groups.

Let’s check which groups Mary is in:

The user account mary is only in the  mary  group.

Let’s check with Tom:

The tom user account—and therefore, Tom—is in the groups tom and sudo.

Let’s try to get Mary to do something that requires sudo privileges.

Mary cannot look inside the restricted file “/etc/shadow.” She gets a mild telling off for trying to use sudo without permission. Let’s how Tom fares:

As soon as Tom enters his password, he is shown the /etc/shadow file.

Just by adding him to the sudo group, he’s been elevated to the elite ranks of those who can use sudo. Completely unrestricted.

Giving Users Restricted sudo Rights

Tom has been given full sudo rights. He can do anything that root—or anyone else in the sudo group—can do. That might grant him more power than you’re happy to hand over. Sometimes there’s a requirement for a user to perform a function that requires root privileges, but there isn’t a justifiable case for them to have full sudo access. You can achieve that balance by adding them to the sudoers file and listing the commands they can use.

Let’s meet Harry, owner of the user account harry. He isn’t in the sudo group, and he has no sudo privileges.

It is useful for Harry to be able to install software, but we don’t want him to have full sudo rights. OK, no problem. let’s fire up visudo:

Scroll down through the file until you get past the group definitions. We’re going to add a line in for Harry. Because this is a user definition and not a group definition, we don’t need to start the line with a percentage sign.

The entry for the user account harry is:

Note that there is a tab between “harry” and the “ALL=.”

This reads as user account harry can use the listed commands on all hosts connected to this network. There is one command listed, which is “/usr/bin/apt-get.” We can grant Harry access to more than one command by adding them to the command list, separated by commas.

Add the line to the sudoers file, and save the file. If you want to double-check that the line is syntactically correct, we can ask visudo to scan the file and check the syntax for us, by using the -c (check only) option:

The checks take place and visudo reports that all is well. Harry should now be able to use apt-get to install software but should be refused if he tries to use any other command requiring sudo.

The appropriate sudo rights have been granted to Harry, and he is able to install the software.

What happens if Harry tries to use a different command that requires sudo?

Harry is prevented from running the command. We have successfully granted him specific, restricted, access. He can use the nominated command and nothing else.

Using sudoers User Aliases

If we want to give Mary the same privileges, we could add a line in the sudoers file for the user account mary in exactly the same way as we did with Harry. Another, neater, way to achieve the same thing is to use a User_Alias.

in the sudoers file, a User_Alias contains a list of user account names. The name of the User_Alias can then be used in a definition to represent all of those user accounts. If you want to change the privileges for those user accounts, you only have one line to edit.

Let’s create a User_Alias and use it in our sudoers file.

Add the User_Alias by typing:

Each element is separated by a space, not a tab. The logic breaks down as:

User_Alias: This tells visudo this is going to be a User_Alias. INSTALLERS: This is an arbitrary name for this alias. = harry, mary: The list of users to include in this alias.

Now we’ll edit the line that we added previously for the user account harry:

Change it so that it reads:

This says that all user accounts contained in the definition of the “INSTALLERS” User_Alias  can run the apt-get command. We can test this with Mary, who should now be able to install software.

Mary is able to install the software because she is in the “INSTALLERS” User_Alias, and that User_Alias has been awarded those rights.

Three Quick sudo Tricks

When you forget to add sudo to a command, type

And the last command will be repeated with sudo added to the start of the line.

Once you’ve used sudo and authenticated with your password, you won’t have to use your password with further sudo commands for 15 minutes. If you want to have your authentication forgotten straight away, use:

Ever wonder where you can see failed sudo command attempts? They go to the “/var/log/auth.log” file. You can view it with:

We can see the entry for user account mary who was logged in at TTY pts/1 when she tried to run the shutdown command as user “root.”

With Great Power…

…comes the ability to delegate portions of it to others. Now you know how to empower other users selectively.