mkdir() and security hole ***** ONE-LINE FIX !! ****

[MFHorn]

> | nice(-255);	/* always win race condition  - fixes security bug */
> 
> 	Unfortunately, this analysis is incorrect.
> The real window
> occurs while the mkdir process is blocked on disk I/O

Still not right.

> 	Incidentally, the fix proposed by jfh at rpp386 (using dir/./.
> as the target of the chown()) doesn't help either.

But it's the right idea.

A couple years ago, I had to fix this bug in one of our systems.  I had
source to mkdir.c, but not to the kernel, and was able to successfully
close the hole completely.


  mknod(dirname);       /* Irrelevant arguments omitted */
  link(".");
  link("..");
  chown(dirname);

The real problem is mkdir trusts dirname to be the directory it just
created, which is not necessarily the case.  Nicing the process only
shrinks the window of vunlerability, but it doesn't close it.

The proper fix is to change 'chown(dirname);' to 'chown(".");' and
add a chdir(dirname); in the right place (with proper error checking).

  mknod(dirname);
  link(".");
  link("..");
  chdir(dirname);
  chown(".");

Now, it doesn't matter where the rmdir/ln magic is performed.  If it's
between chdir and chown, you're too late.  If it's between mknod and
link, you're too early.  If it's between link and chdir, then the chdir
fails with ENOTDIR (remember only root can ln directories).

Andy Rosen           | arosen at hawk.ulowell.edu | "I got this guitar and I
ULowell, Box #3031   | ulowell!arosen          |  learned how to make it
Lowell, Ma 01854     |                         |  talk" -Thunder Road
		RD in '88 - The way it should've been