/usr/local/etc/rc.d/ scripts and non-root user

[Alex Zbyslaw]

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 
while.

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 
descriptor.

--Alex