Linux/Unix – Delegating authority in Linux system
Back to the nautical motif for a moment; just as one ship generally doesn’t have two captains, it is rare that an organization would have two systems administrators. There’s usually not too much benefit in delegating authority in this setting. People are prone to making mistakes. Even a seasoned systems administrator has sometimes deleted files that he/she shouldn’t have or messes up the configuration of something. If two heads think well than one, then four hands also might make more mistakes than two.
The use of sudo as alternative
If you’re the head systems administrator (or the only one) you can “deputize” your co-workers by installing and configuring the program sudo. In Unix/Linux speak, the term ‘su’ means superuser – that is, root. Only root has true administration rights and privileges, so this program allows others to “do” su, hence the name, sudo. Ok, Sheriff, time to fight the bad guys. Let’s see what your deputies can do.
su can also stand for switch user. For example, if you had two accounts on a machine – let’s say bob and harry – you could log on as ‘bob’ and do: su harry and then work as harry.
Your distribution should have this very popular program among its packages. If it doesn’t, you can go to: http://www.courtesan.com/sudo and get Todd Miller’s great application. After you’ve installed it, you have to create what’s called a sudoers file. You do this by typing:
as root. This is essentially a special version of the text editor vi just for creating and editing the sudoers file. Here is an example sudoers file I have for my home network. It is not really as complicated as most are, but it gives a good basic idea of what you need to do to let other users help you out with some administration tasks.
# This file MUST be edited with the ‘visudo’ command as root.
# See the sudoers man page for the details on how to write a sudoers file.
# Host alias specification
# User alias specification
User_Alias TRUSTED = mike, maria
# Cmnd alias specification
Cmnd_Alias INTERNET = /usr/sbin/traceroute, /usr/sbin/ntpdate
Cmnd_Alias KILL = /bin/kill, /usr/bin/killall
Cmnd_Alias TOOLS = /bin/mount, /bin/umount
# User privilege specification
root ALL=(ALL) ALL
TRUSTED ALL=INTERNET, KILL, TOOLS
Let’s break this down. First of all, we add the line
User_Alias TRUSTED = mike, maria
That means that the users mike and maria become the “trusted” users. And what are they trusted with? Jump down to the last line for a second. They are trusted with commands in the group INTERNET, KILL and TOOLS. What are those commands? Jump back up to the section
These trusted users can use ntpdate, for example, to keep the computer’s time correct. More information on that command later.
I’ve created a KILL group (sounds like Mafia hit men!) so other users can kill runaway process that can only be shut off by root normally. Some server process may have a problem and you might have to shut down that process. Starting it again is something that’s not included here however. It might be best for these deputized users to call the “real” system administrator and if that’s you, for example, you may want to check out the configuration files for certain servers before you start them again. You may have to mount floppies or other partitions to get data from them, and that’s where the TOOLS section comes in handy. When the user executes a command that’s authorized in the sudoers file, he/she first needs to type
and the command. For example, if you wanted to update the machines clock to the exact time, you would type:
sudo ntpdate atimeserver.nearyou.gov/edu
Then you need to type your user password. If you make a mistake, sudo will hurl insults at you. You can add more commands and users to your own sudoers file. Whatever you think is prudent in your situation. There is some possibility for abuse. Use your best judgment.
Taking care when working as root
As I mentioned, there’s a chance of doing some damage when you work as root. There are other ways to protect yourself besides putting aliases in your .bashrc file. One of them is using the program su.
su lets you work as root when you’re logged in as another user. Good practice dictates that you disallow root logins from remote machines, so if you’re performing administration tasks remotely, su is irreplaceable. The remote machine lets you log in as user fred, for example, and then you just type:
and type the root password. For all intents and purposes you’ve got a root terminal open now. That means that you can do anything – just as if you had logged in as root in the first place. You’re really running the same risks by working as root, but you’ve at least eliminated the risk of logging in as root. That’s quite important from a security standpoint. The real advantage to using su is the possibility to carry out individual commands. Let’s say you’ve downloaded an application and it’s only available as source code in a tarball. You can download the source code to your user directory and as a user you can run the configure and make scripts provided with most tarballs. That way, you minimize the risks of compiling the software. If you’re satisfied with the binary file (the application itself), then you can use ‘su’ to install the application and its accompanying documentation in the usual application and documentation directories. Here’s what you’d do:
su -c “./make install”
You need to add the -c (command) switch and put the actual command in quotes. Then type the root password.
As you see, you can run any command that root can. That, of course, means that you need to know the root password, so this is something that only the system administrator should do. It’s not a good idea to be giving your password to other users so they can run commands. They can do that with sudo, as we mentioned earlier.
You can also use su to do things as other users. You’re not just restricted to doing things as root. This might come in handy if you’ve got two accounts on a machine. Instead of having to log in as the other user, you could, for example, read a file that you’ve restricted permissions for. Let’s say you’ve got a file called my_ideas and you’ve removed read permissions to it for your group and for others. Instead of logging in, you can type:
su mgsotoso -c “less /home/ mgsotoso/my_ideas”
and you will now be asked for fdavis’ password. Now you can access files from your other user account without having to log in. Other users may also give you their passwords to access things in their account. I question the wisdom of doing that, but in an emergency it’s an option. A co-worker who’s ill may give you his/her password to access important files. That’s acceptable in that kind of situation it seems, but the ill worker should promptly change his/her password as soon as he/she’s back at work.
As you can see, if used correctly, su is a great tool for getting administration tasks done safely. It’s also useful as a time and trouble saver. Just make sure you don’t abuse it.