why chroot(1) isn't setuid

[Dick Dunn]

In article <162 at apmpyr.nzapmb.co.nz>, pgfdp at nzapmb.co.nz (Paul Fox ) writes:
. . .
> Can someone tell me -- if the problems of chroot'ing are due to being
> able to ln an suid'ed file (e.g. "ln /bin/su /tmp; chroot /tmp ..."),
> and if the problems of set-uid shell scripts are due to being able to
> ln to an suid'ed script, could it be that we could kill several birds
> with one stone by preventing hard links to files with the suid bit set,
> and conversely not setting the bit on files with multiple links?...

But no, the problems of chroot are more than just ln to setuid files, and
similarly with setuid shell scripts.  Moreover, the suggested change (prevent
hard links to setuid files) introduces a significant restriction to things we
can do now, in order to allow something which *might* be useful (unre-
stricted chroot) that we can't do now.  It is fairly common to have
multiple links to a file with different names, such that the program
figures out what it's supposed to do based on its name.  It seems unnatural
to prohibit this for setuid programs, particularly since they might have
significant "validation" code which can be shared among multiple tasks.
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...I'm not cynical - just experienced.