Re: seduid scripts

[ersmith@netcom.com (Eric R. Smith)]

>>> > [about /bin/scripter]
>>> 
>>> This sounds an even more unholy mess than one incidence of / -> \ conversion
>>> in the kernel! Anyway, it's just one more security hole, not that there
>>> aren't one or two already! :-)
>>
>>Why is that an security hole?  `/bin/scripter' would be just another shell
>>which happens to be setuid-root (just like `su').

>It's just one more program which could be compromised.

As are any setuid scripts. So why don't we just disallow setuid scripts?
Then there's no problem: exec can just read the line after #!, shift all
the arguments down by one, insert the shell file name, and continue on
its way. In fact, that brings up another reason why it should be done in
the library: the kernel doesn't handle ARGV parsing. Maybe it should; but
that would mean a whole new system call, and a lot of unnecessary code
duplication.

>Exec should preferably be an atomic action. Also, there is an implicit
>assumption that you hold your executables in /bin. What if the script is for
>something other than /bin/[c]sh, maybe you want to run /exec/bloggs/gruncher
>and don't have a /bin on the current drive? Putting the parsing of the #!
>magic number in the kernel would make the kernel self contained, and hence
>less able to be totally fouled up by the half-clued or clueless.

If the script isn't setuid, then there's no problem (exec can execute
it directly, it doesn't need a setuid /bin/scripter). If the script
is setuid, then you can (a) require that there be a /bin/scripter,
or (b) use an environment variable like $SETUIDSCRIPT to override the
default assignment.

If we're worried about the half-clued or clueless, then I would say that
we should be more concerned about naive TOS users who don't know that /
is a unix path separators than unix experienced people who are trying
to build setuid shell scripts.

Eric