setuid shell scripts
Chris Torek
chris at mimsy.UUCP
Tue Nov 15 13:11:48 AEST 1988
In article <855 at cantuar.UUCP> greg at cantuar.UUCP (G. Ewing) writes:
>and Chris Torek indicated in an earlier posting that there was a
>problem that was *completely independent* of shell semantics.
I hope that this is a paraphrase, for I did not mean that. If the
interpreter does nothing with the script, there are no setid problems.
>Presumably this means that it doesn't matter if the shell isn't
>a shell.
It must pay some attention to its arguments. Moreover, it must interpret
argv[1] or argv[2] as a file name.
>Maarten Litmaath again:
>>\removing the setuid-#! facility is wrong.
>>Questionable; every interpreter would have to take care of things, while
>>it should be the kernel who's getting them straight.
>I'd be quite happy for the kernel to do it right. I was just saying that
>disabling the facility altogether might be overkill.
It might; but there are no known uses for the (now disallowed) kernel
invocation of set-id #! scripts that are also secure. ksh can be made
to interpret set-id scripts, but it works without #! doing the ID setting;
one installs ksh itself setuid root instead. Similar changes could be
made to sh and csh.
Again: if your kernel implements `#!', but ignores set-id bits, or
if you have no set-id scripts, or if you do not have `#!' at all,
you are safe. A safe way to run some script set-ID is to write a
C program that is set-id that runs `execl("/path/to/interpreter",
"interpreter", "-options", "/path/to/script", (char *)0)', and then
exits if that fails.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris at mimsy.umd.edu Path: uunet!mimsy!chris
More information about the Comp.unix.wizards
mailing list