Sidebar: Security Issues

Programs that launch pipelined tasks pose potential security problems because they open the possibility of a system intruder's substituting an unauthorized program of the same name for one of the pipeline's component programs. For example, an unauthorized program could be named who and placed on the path so that it gets executed in place of the standard who.

To write absolutely secure C programs using pipes, always use the absolute path to the command(s) to be executed, i.e., never search the PATH. The pipe() method will not search the PATH so long as communicating tasks are launched with execl(), execv(), execle(), or execve(). The other two members of the exec() family of functions, execlp() and execvp(), as well as popen() and system() do search the PATH.

While completely ignoring the PATH is too restrictive for most serious applications, there are coding practices that do improve security without sacrificing the use of the PATH:

1. Always make sure the PATH is set to search the system directories first. Never search the current directory first, especially the root user. Always make sure the command being executed is the one you really want to execute. In particular, you should never use a path like:

PATH=.:/bin:/usr/bin

which searches the present directory first.

Programs that use popen() can enforce this restriction by setting the PATH before executing the command(s) to be piped:

char *com_str="PATH=/bin:/usr/bin; who|sort|pr";

This prevents a user from tinkering with the PATH even if shell access is possible.

2. Avoid calling programs that can escape to the shell. At the very least, these programs allow an intruder to shell out and change the PATH to search directories other than the system directories first. This change alone, is enough to allow the intruder to force an unauthorized version of a system command to be executed.

3. Avoid setting the user ID on executables, especially on executables owned by root. Setting the user ID bestows the file owner's permissions and not the permissions of the user executing the file. Consider the example executable, test:

-rwx--x--x  1 root usr test

Suppose test tries to read the data file datafile:

-r--------  1 root usr datafile

User root owns test and if user steve tries to execute test, a read error occurs, because steve doesn't have permission to read datafile. After setting the user ID with the chmod u+s command:

-rws--x--x  1 root root test

Now if user steve executes test, datafile can be read with no errors. At the very least, user steve could affect the datafile if shell access is possible.