Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!vrdxhq!verdix!ogcvax!littlei!reed!psu-cs!mmason From: mmason@psu-cs.UUCP (Mark C. Mason) Newsgroups: comp.os.minix Subject: Re: SETUID on mkdir and rmdir Message-ID: <425@psu-cs.UUCP> Date: Sat, 4-Jul-87 10:52:38 EDT Article-I.D.: psu-cs.425 Posted: Sat Jul 4 10:52:38 1987 Date-Received: Wed, 8-Jul-87 00:43:02 EDT References: <8707030732.a029212@Louie.UDEL.EDU> Reply-To: mmason@psu-cs.UUCP (Mark C. Mason) Distribution: world Organization: Dept. of Computer Science, Portland State University; Portland OR Lines: 26 In article <8707030732.a029212@Louie.UDEL.EDU> ESC1332@ESOC (K.Keyte) writes: > >Does everyone have SETUID on their mkdir and rmdir? Standard UNIX does >not, as the mkdir and rmdir are just normal file operations. In MINIX, if >SETUID is on it means that any user has the permission to create and delete >directories anywhere is the file system. I've tried, however, taking the >SETUID bit off, but I can't seem to create ANY directories from normal user >accounts in this state. In non-4.[23] versions of UNIX, mkdir and rmdir must be suid to root as they call mknod(2) directly (which only root can execute). Though I haven't actually looked, ownership and permissions are probably checked from within user mode. This caused a security problem (in fact mentioned on page 282 in THE BOOK under "Famous Security Flaws") since mkdir created a root owned directory with mknod(2), then called chown(2) to set owner- ship, creating a small window of opportunity. Starting with BSD 4.2 UNIX, the problem was addressed by creating a new system call, mkdir(2), which does the whole operation from within the kernel (this, in part, is why I habitually refer to non-BSD4.[23] versions of UNIX as "pre-BSD" :-). Mark tektronix!psu-cs!mmason