Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!gatech!ncar!ico!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.unix.wizards Subject: Re: why chroot(1) isn't setuid Summary: better to keep existing restrictions Message-ID: <12565@ico.ISC.COM> Date: 9 Dec 88 07:20:15 GMT References: <1971@van-bc.UUCP> <572@comdesign.CDI.COM> <5517@medusa.cs.purdue.edu> <162@apmpyr.nzapmb.co.nz> Organization: Interactive Systems Corp, Boulder, CO Lines: 21 In article <162@apmpyr.nzapmb.co.nz>, pgfdp@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.