setuid on shell scripts
Running software as root without requiring a root password is the subject of a number of tutorials on the web, and although it may seem a little bit confusing, it's fairly simple. Inevitably, users want to run shell scripts as root, too. After all, they're considered a 'program', so why not? Unfortunately, there are unseen bumps in the road to Unix convenience.
The tutorial
Many tutorials show this method for creating a script that runs as root automatically.
Open a text editor, and type up your script:
#!/bin/sh
program1
program2
...
Save the file as something.sh.
Open a terminal, and enter the following commands:
$ su
[enter password]
chown root:root something.sh
chmod 4755 something.sh
exit
Then, finally run it with ./something.sh, and it'll have root access!
...or not. Most likely, you'll get the same error messages that you did before you ran those commands. If your script does actually work, go ahead and skip the rest of this tutorial. If you experience this problem, read on.
The problem
The instructions are fairly straightforward. Create the shell script that you want to execute, and change the owner and group to root (chown root:root). Now comes the command that's supposed to do the magic:
chmod 4755
Let's break this down a little bit. The 755 part means that there's read/write/execute permissions for the owner (root), and only read/execute permissions for everyone else. This makes sense because you want everyone to be able to execute the script, although you don't want everyone to be able to modify what it does.
Now for the 4 prefix. This means that the specified file will have the setuid bit set. This means that whatever is run will have the permissions of the owner. Since we set root as the owner, this will do exactly what we want. Perfect!
Except it doesn't. Well, the truth is actually that the setuid bit is disabled on a lot of *nix implementations due the massive security holes it incurs. If the method originally mentioned doesn't work for you, chances are that your Linux distribution has disabled setuid for shell scripts.
The solution(s)
One way of solving this problem is to call the shell script from a program that can use the setuid bit. For example, here is how you would accomplish this in a C program:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int main()
{
setuid( 0 );
system( "/path/to/script.sh" );
return 0;
}
Save it as runscript.c. You'll need the gcc compiler. If you don't have it already, look for it in your package manager. You can usually the majority of your compiler tools with one large package, but many distros also offer the option of installing gcc by itself.
Once you have it, compile it at the prompt:
gcc runscript.c -o runscript
Now do the setuid on this program binary:
su
[enter password]
chown root:root runscript
chmod 4755 runscript
Now, you should be able to run it, and you'll see your script being executed with root permissions. Congratulations!
Another alternative, if you've got it installed, is to prefix all the commands in the shell script with 'sudo'. Then set up the permissions so that a password is not required to run those commands with sudo. Read the manpage for more information.
Conclusion
With all that said, running shell scripts with setuid isn't very safe, and the distro designers had a pretty good idea of what they were doing when many of them disabled it. If you're running a multiuser Unix environment and security is an asset for you, make sure that your scripts are secure. A single slip can result in the compromising of an entire network. Only use them when absolutely necessary, and make sure you know exactly what you're doing if you do decide to use them.