Safely Running Programs as root
This article is more about ending a bad habit than serious programming. How many of you regularly become root to do some routine task? I thought so. And, worse yet, how many of you just stay logged on as root because you know you can do what you want? That's too many.
One very common reason to become root is to run a shell script needing root privileges. For example, starting PPP is usually done by a script that must be run as root. For this article, I use that example as the basis for the code shown in Listing 1. There is nothing special about it—it just happens to be a common example. This same program can be modified to run other scripts requiring root privileges or to do other root-like tasks.
The first thing you need to understand is the meaning of the phrase “set UID on execution”. This concept is the only patented feature in Unix. It is the ability to “look like another user” while executing a program. The most common example is running the passwd program to change your password. If you look at the permissions on the password file you will probably see something like this:
-rw-r--r-- 1 root 1260 Nov 3 10:05 /etc/passwd
Notice that only root has permission to write to the file. Now look at the permissions on the password program:
-rwsr-xr-x 1 root 10636 Jun 6 1996 /usr/bin/passwdNotice there is an s where you would expect an x to indicate execute permission for the owner. The s indicates the “set UID” bit is set.
Having the UID bit set means when you, as an ordinary user, execute the passwd program, the program is executed as if you were root. This enables you to change your password entry in /etc/passwd, but you won't be able to do anything else. The program itself (/usr/bin/passwd) is responsible for making sure you do only reasonable tasks; since you don't have write permission to the program, you can't change it.
If you understand set UID, you can now see how important it is in guaranteeing program security. For example, if your program has a way to get into the shell, it has a security hole.
While we are talking about security holes, one other approach is allowing shell scripts to run set UID. This ability actually exists in some Unix systems, and it opens huge security holes. Ideally, you must be able to read the script and trust it.
The program I wrote to start and stop PPP is in Listing 1. Its purpose is execution of the appropriate shell script to start or stop PPP, depending on whether it is called with an argument of on or off.
Most of the code is explained in the comments, but let me further explain a couple of items. First, I chose to set the PATH environment variable to a reasonable set of directories. It is important to do this to guarantee it's impossible to sneak an unauthorized executable into the program. Second, I used the execle system call to execute the appropriate script. execle passes the new environment to the called program, so it inherits the search path I set instead of the path of the calling user.
I also specified the full path name of the programs to run (see the #define lines)—another security consideration. It should be unnecessary after PATH has been set, but it's an inexpensive safety precaution.
Finally, the program must be installed properly. Once you have built the executable (make ppp), you should become root, move it to an appropriate directory (e.g., /usr/local/bin) and correctly set the permissions.
If you want anyone to be able to run the program, make sure it is owned by root and set the permissions to 4711. The leading 4 specifies setting the set UID bit. If you have a particular group of people you want to allow to run the program, change the group owner of the program to the appropriate group with permissions set to 4710.
That's it. If all goes well, you now have one less excuse to work logged in as root.
If you need a system for allocating various root tasks to ordinary users, solutions are readily available. Check out the sudo and super programs, which are included in most Linux distributions.
Phil Hughes is publisher of Linux Journal. In a past life he was a Unix systems programmer.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open