Classic Shell Scripting

Setuid Shell Scripts: A Bad Idea

Many problems with Unix security hinge on a Unix file attribute called the setuid (set user ID) bit. This is a special permission bit: when an executable file has it turned on, the file runs with an effective user ID equal to the owner of the file. The effective user ID is distinct from the real user ID of the process, and Unix applies its permission tests to the process's effective user ID.

For example, suppose that you've written a really nifty game program that keeps a private score file showing the top 15 players on your system. You don't want to make the score file world-writable because anyone could just come along and edit the file to make themselves the high scorer. By making your game setuid to your user ID, the game program can update the file, which you own, but no one else can update it. (The game program can determine who ran it by looking at its real user ID, and using that to determine the login name.)

The setuid facility is a nice feature for games and score files, but it becomes much more dangerous when used for root. Making programs setuid root lets administrators write programs that do certain things that require root privilege (e.g., configure printers) in a controlled way. To set a file's setuid bit, type chmod u+s filename. Setuid is dangerous when root owns the file; thus chown root file followed by chmod u+s file is the problem.

A similar facility exists at the group level, known (not surprisingly) as setgid (set group ID). ...