> > the latter is 100% standard UN*X -- normally, the set-id bits for
> > scripts are ignored, because (since most un*xes don't have /dev/fd/*)
> > there's no safe way to do set-id scripts.
> 
> I'm not arguing about the merits of setuid scripts, however, SunOS, 
> HP/UX, and Solaris (if /dev/fd isn't mounted) happily run setuid scripts
> the old fashioned way.

Hmm, the last time i checked this, this wasn't the case... however...

> There's a lot of holes true, but it can be 
> done securely-if the file and dir permissions are correct and you use the
> "break" arugment list processing option, or am I missing something else?

no matter where your s-uid script is, if you link to it (soft or
hard), execute the link'd version, remove the link, and replace it with
your own script between the time the kernel getattr's the script
and the time that the shell opens it, you'll have a set-uid shell
running your own script.

It's a standard race condition.  Nothing you can do about it (short
of disallowing all types of links to setuid scripts, and that's not
possible, because what if the links were there before it was made
set-uid?) short of /dev/fd (or equivalent) will kill that race
condition.


chris

------------------------------------------------------------------------------