Xref: utzoo news.admin:4348 news.software.b:1809 comp.bugs.sys5:718 comp.bugs.misc:195
Path: utzoo!attcan!uunet!husc6!rutgers!apple!vsi1!lmb
From: lmb@vicom.COM (Larry Blair)
Newsgroups: news.admin,news.software.b,comp.bugs.sys5,comp.bugs.misc
Subject: Re: mkdir() and security hole   ***** ONE-LINE FIX !! ****
Keywords: spoiler - helps both AT&T and Public domain mkdirs.
Message-ID: <1313@vsi1.COM>
Date: 22 Dec 88 18:08:44 GMT
References: <9466@merch.TANDY.COM> <851@husc6.harvard.edu> <379@skep2.ATT.COM> <871@husc6.harvard.edu>
Reply-To: lmb@vicom.COM (Larry Blair)
Organization: VICOM Systems Inc., San Jose, CA
Lines: 18

In article <871@husc6.harvard.edu> ddl@husc6.harvard.edu (Dan Lanciani) writes:
=In article <379@skep2.ATT.COM>, wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) writes:
=| nice(-255);	/* always win race condition  - fixes security bug */
=| 		/* nice(-255) is not very nice, but root has its privileges */
=| 		/* works with official mkdir and Doug's */
=| 
=	Unfortunately, this analysis is incorrect.  The real window
=occurs while the mkdir process is blocked on disk I/O to, e.g., look
=up elements of the path name of the file to chown().

I don't what version of Unix you run, but I don't know of one that would
do ANY disk I/O for the chown, since the mknod would have brought all of
the elements into core and, being -255, no one else could have caused the
kernel to de-cache the inodes and buffers.  I'm also pretty sure that there
is no danger in this case of losing the CPU due to timeout.  I'm sure that
some kernel hacker can tell us whether nice(-255) can be preempted.
-- 
Larry Blair   ames!vsi1!lmb   lmb@vicom.com