/usr/local/etc/rc.d/ scripts and non-root user
xfb52 at dial.pipex.com
Mon Feb 11 11:00:15 UTC 2008
Matthew Seaman wrote:
>gs_stoller at juno.com wrote:
>>On Wed, 06 Feb 2008, Alex Zbyslaw wrote
>>>Setuid/gid bits on shell scripts aren't considered safe, however and may
>>>even be disabled.
>>THERE IS NO REASON FOR THIS, JUST USE THE FILE-SYSTEM TO PROTECT THE
>>FILES (MAKE THEM NOT WRITEABLE).
>There's no particular reason that setuid bits on scripts are dangerous
>nowadays. However in the dim and distant past (before the millenium)
>there used to be a race condition on opening files that meant it was
>trivial to use a setuid script to get a shell running under the target
>UID. The horror of this situation seems to have branded itself so deeply
>on the Unix psyche that even now, when that race condition has been
>eliminated for many years, there is still a lingering reflex response:
>"setuid scripts bad."
Thanks for the clarification.
Serves me right for not adding a disclaimer since I had the feeling this
had been fixed; but with security better to err on the side of caution.
Haven't need a setuid shell script in 15 years and I think I'll still
keep it that way :-) It wasn't the right answer to the OPs original
problem, in any case.
How about: setuid programs of any kind are dangerous. It's very easy to
accidentally allow far more than you originally intended. Look at the
effort sshd had to go to with privilege separation and that was from a
project where security is the watchword. They still got it wrong for a
How many setuid root programs gave you root shells because they used
"more" at some point? Dim and distant past, maybe, but we all know that
history has a habit of repeating itself.
Weren't there also tricks you could play with IFS if the script didn't
set it? And I'm sure that there was some other race condition to do
with ^C in the shell, as well as the file-renaming trick which played on
the race condition in the kernel, which BSD has fixed by using a file
More information about the freebsd-questions