root

The previous lesson said that root, the superuser, can do anything on the machine, and that ordinary users borrow that power for a single command with sudo. This lesson is the promised explanation of where that permission comes from, and why you almost certainly do not have it.

Two ways to become root. You have seen sudo. There is also su, which substitutes users: with a username it becomes that user, with no username it opens a root shell.

$ su

It asks for the password of the account you are becoming, so plain su needs the root password. On Debian and Ubuntu the root account has no usable password at all, by design, and su simply fails:

$ su
Password: 
su: Authentication failure

That is not a misconfiguration, it is the point. Everything goes through sudo instead, and sudo asks for your own password. The difference matters for more than convenience:

• A root shell stays root until you leave it, so every typo in it is a root typo. A sudo command is root for that one command.
• sudo records who ran what, in the system log. su records that someone became root and nothing after that.
• Taking sudo away from one person is a one line change. Sharing a root password means changing it for everybody.

If you genuinely need several root commands in a row, sudo -i gives you a root shell through the same mechanism, logged and with no shared password. Use it deliberately and leave it when you are done.

Where the permission is written down. The system does not let just anyone run sudo. The list lives in /etc/sudoers. You cannot read it:

$ cat /etc/sudoers
cat: /etc/sudoers: Permission denied

which is reasonable, since it is the file that decides who is trusted. A line in it looks like this:

pete    ALL=(ALL:ALL) ALL

Read as four answers to four questions: who (pete), on which machines this file is valid (ALL, since the same file can be copied to many), as which user and group they may run things (ALL:ALL, so anyone including root), and which commands (ALL, meaning anything).

That last field is the interesting one, because it does not have to be ALL. An administrator can grant exactly one privilege and nothing else:

pete    ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

Now pete can restart that one service without a password and can do nothing else as root. If you ever need a single administrative action as part of your work, this is what to ask for. It is a much easier request to grant than "please give me sudo".

In practice it is a group, not a list of names. Adding every user by name would be tedious, so the stock file grants sudo to a group instead. A percent sign means group:

%sudo   ALL=(ALL:ALL) ALL

On Debian and Ubuntu that group is called sudo; on Red Hat, Fedora and their relatives it is wheel. So "giving someone sudo" is almost always just adding them to that group, and taking it away is removing them. This is why the first account you create when you install Linux yourself has sudo: the installer puts it in that group. Accounts made for you on someone else's server are not.

You can check where you stand without any special access:

$ groups
pete students rnaseq

No sudo or wheel in that list means no root access, whatever else you may have been told. To see who does have it:

$ getent group sudo
sudo:x:27:jane

Editing the file: use visudo. If you do administer a machine of your own, do not open /etc/sudoers in an editor directly. Use:

$ sudo visudo

It opens the file in your editor, and then checks the syntax before it saves. That check exists because a syntax error in sudoers makes sudo refuse to work at all, and on a system where root has no password and sudo is the only route to root, a broken sudoers file can lock every administrator out of their own machine permanently. visudo turns that into a message telling you which line is wrong. Modern systems also read /etc/sudoers.d/, so the usual practice is to put a small file per grant there, with visudo -f, rather than editing the main file.

What this means for you on a shared server. You will not have sudo, and asking for it is unlikely to work. Not because anyone doubts you: the machine has other people's data on it, and root can read and destroy all of it, so administrators hand it out narrowly. When you hit something that needs root, there are better moves than asking:

• Installing software is the usual reason people think they need root, and it is the one case where you simply do not. Conda installs into your home directory as an ordinary user, which is what the Your Environment section covered.
• Reading a colleague's data is a group problem, not a root problem. Ask to be added to the group that owns the files. That is a small, safe request.
• A tool that must be installed system wide, or a service that must be restarted, is a request to the administrator: name the exact command, and mention that a single sudoers line will do it.

And if you try anyway, you get the message from the permissions section:

pete is not in the sudoers file. This incident will be reported.

It is not an idle threat, though it is a mild one: the attempt is written to the system log, which is what "reported" means. Nobody minds you finding out where the edge is. It is worth knowing that the edge is watched.

Finally, respect it. On a machine where you do have sudo, your own laptop or a virtual machine, remember that root has no safety net: no confirmation, no undo, no permission to protect you from yourself. The classic disaster is a stray space in sudo rm -rf / something. Pasting a command from the internet with sudo in front of it deserves the same suspicion as running an unknown program as an administrator on any other system, because that is exactly what it is.