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