how to setuid for shell scripts on ultrix?

[Guy Harris]

>I have always been under the impression that setuid shell scripts
>intentionally do not work for BSD derived unixes in deference to security
>considerations.

What actually happened is that due to a particular
unclosable-without-"/dev/fd" security hole, Berkeley sent out a 4.xBSD
patch to disable set-UID shell scripts, which some vendors have picked
up.

Prior to that patch, BSD quite happily let you write setuid shell
scripts, and happily let anybody who knew the trick get an interactive
shell running with the user ID of such a script.

>However, our experience with ultrix 4.0 (and I believe 2.0) is that *if
>and only if* "#!/bin/some-shell" is the first line of the script, then
>setuid will work for that script.

That's because if the script doesn't begin with a "#!" line, the shell
script isn't "directly executable" - i.e., an "execv()" or "execl()"
call specifying that script will fail, while if it begins with a "#!"
line, on many systems the "execv()" or "execl()" call will succeed.  The
way that works on a large number of those systems is that the code that
implements "execv()" ("execl()" generally being a wrapper around it)
notices the "#!" line, parses it, and runs the program specified by the
pathname.  That's generally the same code that handles the set-UID bit,
so it just runs the program in question set-UID.

For non-"#!" scripts, the code that calls "execv()" or "execl()" has to
notice the failure and decide to run a shell with that script.  The code
in question is generally running as ordinary user-mode code and
therefore cannot simply decide to run the shell in question set-UID.

>However, does this behaviour not violate the whole point of not
>allowing setuid shell scripts - i.e., that they are a security risk?

It does, but at the time the particular security hole that provoked
Berkeley into making the patch in question wasn't known, so it was
considered OK to have the system allow shell scripts to be set-UID.

>And, if it was indeed the intention to allow setuid shell scripts, why
>not go all the way and not require the leading "#!/bin/shell" as is the
>case with System V?

No System V system with which I'm familiar allows scripts *not*
beginning with "#!" to be set-UID.  Certainly none of the vanilla
from-AT&T versions of S5 I've seen the code of (S5"R1", S5R2, S5R3) do. 
None of the S5's from AT&T prior to S5R4 even support "#!" in the
fashion I described above; S5R4 does, and also, I think, fixes the
particular security hole in question.  (There may well be other holes
nobody's found, or at least told enough people about, yet.)

Both System V *and* BSD (and the earlier UNIX systems on their branches
of the family tree) have shells that will do the aforementioned
operation for scripts that don't begin with "#!", and all but some
systems *very* far back on the family tree have routines ("execlp()",
"execvp()") that do stuff similar to what the shells do.

In other words:

Few if any UNIX systems require a "#!" line for executable shell scripts
- or, at least, scripts executable as commands by the shells and
executable by programs using "execlp()" or "execvp()".

Few if any UNIX systems *don't* require a "#!" line for set-UID scripts,
although some shells have alternative mechanisms for handling them that
may allow them to work without "#!" (e.g., some versions of the Korn
shell) and some other programs exist to handle them as well.