2009-12-10, 22:16(-08), haomiao:

Yes, and to clarify the security hole, if you have a setuid ksh
script (for instance /opt/x/bin/foo starting with #! /bin/ksh
-)), one can make another script by the same name and put it in
$PATH (like echo sh > ~/bin/foo; chmod +x ~/bin/foo), then

chdir("/opt/x/bin");
execl("foo", "foo", 0);

Then the system will change that to:

execl("/bin/ksh", "ksh" (or "foo" depending on the system), "-",
"foo", 0); (*)

With the process euid being the owner of /opt/x/bin/foo

But ksh will interpret ~/bin/foo instead of /opt/x/bin/foo
because ~/bin is in $PATH and not /opt/x/bin

(*) Some systems will change it instead to
execl("/bin/ksh", "ksh" (or "foo" depending on the system), "-",
"/dev/fd/3", 0);
where fd 3 is open to /opt/x/bin/foo. That fixes both that hole
and the race condition one.

Note that not all systems support setuid scripts, and on some,
the support can be disabled/enabled at run time.

In any case, a setuid shell script especially a ksh one is most
likely to be a security hole, one should avoid that at all cost.

--
St phane