
Setuid shell scripts not allowed
: We argued long about SUID scripts. I think the reason we made the switch
: entirely disable SUID scripts is that we didn't want existing programs to
: fail mysteriously. Anyone who has an existing SUID program would be
: unhappy if it failed mysteriously, without any error indications. I think
: the big arguements were whether to just set errno, or to do a kernel
: printf(). (Consider the consequences of the latter.) Once you decide that
: you are not going to implement the FD device in the release currently being
: developed, so that the hole is not immediately fixable, you have to
: consider irritable customers who care about incompatibilities. BSD has no
: such problem with their customers.
Why not make it customizable? This need not be painful. A kernel
variable that can be set with adb would do.
On the other hand, the kernel already has the info from the #! line, so
it could conceivably determine if the interpreter in question is
willing to do setuid emulation.
: I think I see how perl might emulate suid perl scripts, if perl is itself
: SUID and if you trust perl to have no holes of its own.
I don't even trust C to have no holes in it... :-)
Actually, the ordinary Perl interpreter isn't setuid. If it wants to emulate
the setuid bit, it executes another copy of the interpreter that IS setuid.
Otherwise, the ordinary interpreter could never know the effective uid that
the script was invoked under. And this is important, as we'll see below...
: Unfortunately,
: most SUID scripts are not written in perl. What is more, I can't imagine
: much enthusiasm for the task of ensuring that any shell interpretor has no
: holes, not to mention one as powerful as perl.
Shells will have more difficulty because of the multiple-levels-of-substitution
semantics. Perl is a bit more straightforward in that there's generally
only one level of semantics, so that there is little divergence between
what you think you see happening, and what's really happening.
On top of this, when Perl detects that its effective uid doesn't match
its real uid, it does dataflow analysis at run-time to detect when
insecure data is going to be used to do something dangerous. Not even
C will do this for you. It's certainly possible to get around the
mechanism, but it will catch almost all the common blunders.
For this reason, I'd much rather write a setuid program in Perl than in C.
It gripes me to have to put a C wrapper around the script, because the
script itself is architecture independent, and the wrapper isn't. Which
means that I can't just plonk the script into my architecture-independent,
NFS-mounted bin directory, but I have to go out on every architecture, find
a place to put the wrapper, write it, compile it and chmod it.
Bleah, I say. System administration is already hard enough.
Larry Wall