Wednesday, July 5, 2017

If you’ve been using Linux for any length of time, at some point in some tutorial or troubleshooting guide you’ve more than likely encountered Linux’s magic word: “sudo”. A casual observer probably can tell you that it’s used to access restricted functions on your computer, but there is much more to it than that.

My hope is that by taking a moment to dig into the history and inner workings of this command, you will be better equipped to utilize — and respect — the power of “sudo”.

To understand “sudo”, it helps to look at Linux’s ancestor, Unix. The Unix operating system was invented back in the days when computers took up entire rooms, and they usually were found only on university or corporate campuses.

Access typically was provided to as many people as possible through a system of cables running from the computer to keyboard-and-screen terminals, where users could input commands to be sent back to HQ for evaluation. Users would have individual accounts with privileges limited, so they couldn’t interfere with one another or the core system. To manage everything, an administrator had access to an all-powerful root account.

However, there were times when certain users wanted to provide access to their accounts to other users. That was accomplished through the predecessor to “sudo”, the “su” command. Short for “substitute user,” “su” allows logging into the account of another user (without having to log out of the user’s own) by simply running “su” with the other user’s name as an argument, and entering that user’s password when prompted.

Trading Places

For example, let’s say that Alice and Bob both have their own university computer accounts. Alice is doing a week-long project crunching some numbers, but she will be away for a few days in the middle with no access to the computer, and she can’t put off the work until she gets back. If she simply shares her password with Bob, then he can run “su” with Alice’s username (let’s call it “alice”), enter her password, and maintain her running programs.

To show the transition between users, I have provided an example command prompt, the little bit of informative text that comes before the cursor on the terminal. The example prompt is a very standard one: the text before the “@” separator is the user, and the text after is the name of the computer (the brackets are just to keep things organized).

The “su” command even can be used to switch into the root account. At the same campus computer, if Xavier, the administrator, were away from campus, he definitely would want to line up someone to administer the system as his backup just in case something should go wrong, rather than risk a crash! He could give Yolanda the root account password, and she could assume root from her terminal by simply running “su” by itself, as “su” defaults to root if given no arguments.

With most systems, by default any user is allowed to use “su” to log in as any other user, including root, as long as that user’s password is provided, but the administrator can change this permission.

There are a couple of critical limitations with “su”. The most glaring is that for it to work, you have to share your password with someone else — which is never a good thing to do, no matter how much you trust the other person.

No matter how much Xavier might trust Yolanda with the root password, if she writes it down to remember it and then loses the paper, anyone who finds it would have complete control of the campus computer.

The other problem is that users stay logged in as the substitute user until they run “exit”. If Yolanda is logged in on the root account and forgets that she has full system privileges the entire time, then it’s possible that a wrong keystroke could have disastrous consequences.

This is where “sudo” comes in. The primary function of “sudo”, which stands for “substitute user do,” is to allow a user to run a single command as another user — without requiring the other user’s password — and then returning automatically to the first user’s account, with all the account changing handled in the background.

In our example, Xavier would set up a “sudoers” (sometimes called”wheel”) group to include the user “yolanda” and configure access to the group to be authorized by Yolanda’s own password, rather than the root password.

Then, when Xavier takes off, he doesn’t have to give Yolanda his root password. When she needs to run a command as root, she simply puts “sudo” in front of the command and enters her own password, allowing her to execute the command without leaving her session.

Alice can enable Bob to attend to her projects using “sudo” by asking Xavier to configure “sudo” to allow Bob to access her account, protected by his password. Bob then would have to issue “sudo” with the “-u” option and the user “alice” as an argument to it, followed by the desired command.

Safety Check

Once Unix became the model for personal, single-user desktop operating systems, including many familiar desktop Linux distributions, “sudo” proved to be particularly useful. Most of the time, a typical desktop user will only need to run a couple of commands with root privileges at a time.

Using “sudo” lets them return safely to their unprivileged accounts once each command finishes.

Moreover, if the user practices the good habit of running everything without “sudo” until a command demands it, “sudo” acts as a kind of check that prevents the user from accidentally doing something destructive.

If you’re trying to delete something with “rm” and you accidentally specify a file belonging to root, not having prepended the command with “sudo” would end up saving the file. If your habit were to use “su” instead of “sudo,” and you had forgotten to log out, that file would be gone.

This primer should give you a good idea of what “sudo” is and why it works the way it does, although there are a lot more configuration options that allow users or administrators to use “sudo” to compartmentalize user access even further. As with actual magic words, the power of “sudo” is that the magic happens only when it’s intended.

Jonathan Terrasi has been an ECT News Network columnist since 2017. His main interests are computer security (particularly with the Linux desktop), encryption, and analysis of politics and current affairs. He is a full-time freelance writer and musician. His background includes providing technical commentaries and analyses in articles published by the Chicago Committee to Defend the Bill of Rights.