maart@cs.vu.nl (Maarten Litmaath) (11/30/88)
clewis@ecicrl.UUCP (Chris Lewis) writes:
\... can someone out there explain why chroot is privileged? Or
\why /etc/chroot isn't setuid?
Consider a directory `etc' relative to the new root, containing a file
`passwd', which contains an entry `root', ... Get the idea?
\It seems pretty darn silly that some
\mechanism that can only be used for *reducing* access rights requires
\root permission.
It's a protection mechanism for ROOT: he's the ONLY guy that can do ANYTHING
on a UNIX system.
--
fcntl(fd, F_SETFL, FNDELAY): |Maarten Litmaath @ VU Amsterdam:
let's go weepin' in the corner! |maart@cs.vu.nl, mcvax!botter!maartpgfdp@nzapmb.co.nz (Paul Fox ) (12/03/88)
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@apmpyr.nzapmb.co.nz