Setuid/Setgid (was Re: terminal problems with emacs)
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.
(malc@thing.demon.co.uk) | It's fixed in the new release." -- Help line.
Reply to: