Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: comp.os.minix Subject: Re: SETUID problems with mkdir & rmdir Message-ID: <8308@utzoo.UUCP> Date: Thu, 16-Jul-87 16:59:08 EDT Article-I.D.: utzoo.8308 Posted: Thu Jul 16 16:59:08 1987 Date-Received: Thu, 16-Jul-87 16:59:08 EDT References: <341@louie.udel.EDU> Organization: U of Toronto Zoology Lines: 29 > Of course everyone noticed, after a short time, that the 'cp' command > doesn't maintain the SETUID bit... The finger of shame points at whoever wrote cp, then. V7 cp preserves the setuid bit. > ... There is another problem, however, with the > mkdir and rmdir. They are not normally SETUID (at least, not on UNIX). Sorry, they *are* on Unixes (like V7) which do not have mkdir() and rmdir() system calls. Believe me -- utzoo is a V7. > ... To check that the user actually has > the required access to the parent directory, mkdir performs an 'access' call. > This is almost entirely useless because the setting of the SETUID means that > the caller automatically gets a protection mode permission of 07 (meaning that > all access modes are granted). So, the overall effect is that mkdir and rmdir > can be used by anyone to create and remove directories anywhere! ... Sorry, no, you have misunderstood the fine points of setuid bits and the access() system call. The access() call checks permissions against the "real" userid and groupid, which are *not* changed by the setuid bit. This is the way it works in V7 and true V7-compatible systems, anyway. Making mkdir and rmdir owned by root with the setuid bit on is precisely the right thing to do, unless Minix has done something bizarre. -- Support sustained spaceflight: fight | Henry Spencer @ U of Toronto Zoology the soi-disant "Planetary Society"! | {allegra,ihnp4,decvax,utai}!utzoo!henry