why chroot(1) isn't setuid (was: Dangerous hole in Usenet!)

[Paul Fox]

This topic started in the new.admin groups or somewhere, and it was
explained why chrooting needs to be restricted to root, even though
chroot seems on first blush to result in a restriction of privelege,
not an expansion of privelege.

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?  Of
course, I suppose it would be safe for the owner of an suid file to
link to it.

For symlinks, of course, the permission checking would need to be done
when the link is followed, since you can't follow symlinks backwards
when the "chmod u+s" is done.  Perhaps the suid bit could be ignored
if the inode was reached via symlink?

What would be the cost of this inelegance?  Are multiple links to suid
files necessary?  Would this sort of change be crushed by backwards
incompatibility?

------------
paul fox, currently reachable as pgfdp at apmpyr.nzapmb.co.nz