3. What Not To Do

As desirable as enforcing file access permissions are on a Linux system, there are valid reasons for needing to bypass the checking. Several users run the same program to generate project files that must be accessible to all; a printer queue is hung and the sysadmin has given a local user authority to restart the printer daemon; an ordinary user wants to mount an NFS hierarchy from a file server; a mail delivery program must be able to write into mail files writable only by the mail recipient; and finally, a local user is empowered to perform designated sysadmin functions but the real sysadmin does not want to grant blanket permission to alter everything on the system.

Below we will look at common methods of working around the Linux file access permissions scheme and point out some short-comings of each technique. All these methods "work", in the sense that they function correctly but incur unnecessary security risks. In the next section, we show how sudo(8) controls most of these risks.

3.1. Perhaps You Have Heard Of The su(1) Application?

One technique, used since UNIX™ systems began, is for the user to temporarily assume the privileges of the superuser account. The su(1) changes the identification for the current user by substituting user credentials.

$ id uid=500(reynolds) gid=500(reynolds)
	  groups=500(reynolds) $ su -c id Password: uid=0(root) gid=0(root)
	  groups=0(root),1(bin)...

Example 3. Traditional Approach Using su(1)

There are some problems with this approach:

  • The superuser password is compromised.

    Once anyone other than the system administrator knows the superuser password, everyone will know it. He that wishes to keep a secret must keep it a secret that he has a secret to keep. Promises not to tell are not sufficient security.

  • There is no audit trail.

    With a superuser shell, a user can do anything that the root account can do. We must trust[4]the user to access only the files and programs they claimed to need.

3.2. Please, No Setuid Shell Scripts

Another technology, used by the su(1) program, takes advantage of a neat feature.

Normally, the files accessible to an application or shell depend on who is executing that program. Recall those credentials mentioned earlier? An application executes using the credentials of the user who runs the program.

Stop, wait, there's more!

Files have access permissions but since a program is stored in a file, the program has file access permissions, too.

By setting a special flag, called the set user id bit or setuid(2), we can cause the system to check "credentials" made from the program file access permissions, instead of using the credentials for the user running the application[5].

This ability to use the credentials of an application, instead of those of the user, can be a great boon to multiuser applications such as databases or email delivery agents. The feature has its proper use on a Linux system.

As useful as it is, one must resist the temptation to make a shell program, such as /bin/bash, or a shell script, such as /usr/local/bin/run_as_root, be set user ID to root.

If this were to be done, then any user running that script or application would be able to access any file that the root account could access.

Again, the objections to this method a similar to those we mentioned for the su(1) program: no control, and no traceability.



[4] In security parlance, "to trust" is identical to "be at risk from".

[5] The commands:

# chown root:root /bin/foo # chmod 06555
	    /bin/foo

would give whomever runs /bin/foo the same privileges that the superuser account would have while running the same application.