Hi Jeffrey, > would appreciate it. As far as I can understand it, it gives the > permissions of the file owner to the script at execution time even if > someone else is executing it. Can anybody add technical clarification > to this (or tell me I'm clueless)? > > Can somebody comment on what a setuid root program can and cannot do?
I'm not going to promise too much for this (it is 7am here), but I think I can explain a bit. I just hope it's coherent... The u+s option sets the setuid bit on the executable (there's also an analogous setgid bit for the group id, set by g+s). This says that regardless of who runs the executable, the process created will be owned by the owner of the executable file, rather than the more usual situation where the process is owned by the person who ran the executable. This means that the process can read or write files, kill other processes, or whatever, exactly as if you were logged in as the user who owns the file. It also means that if the process starts up any other processes (like a shell or editor), those processes will also be owned by the file's owner, not the user who executed the file. The setgid bit works similarly, except that group identity is only really relevant to file access. There are system calls to allow the process to temporarily give up it's special ownership, and programs designed to run setuid can use these to avoid security problems. This all leaves us with setuid as a two-edged sword. It can be useful to let non-privileged users access things that they need to under the control of a carefully-written program. It can also be a gaping security hole. If a user is running a setuid program that allows them to start a shell, and the program isn't written to take the possibility into account, then you will get a shell with the user id (and hence access permissions) of the owner of the executable, NOT yourself. If the file was owned by root then your system is now at the mercy of the user, who may not even realise it. The moral of this story is: DON'T make executables setuid (especially setuid root) unless they are designed to run that way, or you are 100% sure that the program can't do anything harmful under _ANY_ circumstances. Just as an example, most of the security problems of older sendmail versions wouldn't have been nearly as much of a problem if sendmail didn't run setuid root. Because shell scripts have a lot of known problems with security when running setuid (there are several known ways in which you can usually get a setuid shell script to run almost any command you want), most modern Unix systems, including Linux (as I recall from the FAQ), don't allow shell scripts to run setuid or setgid. This is a pain, because setuid programs are so useful, but then so is getting your system trashed by someone who feels malicious today. I hope this stuff actually helps... -- M a l c . . . | "We've checked, and it's definitely not a bug. ([EMAIL PROTECTED]) | It's fixed in the new release." -- Help line.
