Subject: Re: mktemp() warning lossage?
To: None <lukem@connect.com.au>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-security
Date: 03/24/1997 02:00:18
[I don't know if I'm on tech-security; please cc: any replies to me.]

here's a wild idea:
	1) extend _gettemp()'s path processing to expand
	   occurences of %u to the username, (or uid) of the current process.
	   It may make sense to restrict this to pathname components,
	   for ease of implementation. (see below)

	2) Extend _gettemp() to unlink and create any  directories
	   resulting from %u expansion, if they don't already exist.
	    In either case the mode gets changed to 700 before continuing.

	3) increase L_tmpnam by the maximum length of a username (or uid).

	4) change the default pathname for tempfiles  to include %u.

Are there races in step 2) that are equivalent to the races that exist
when using mktemp()?  Isn't directory creation ``atomic''?

I'm looking for a change we can make inside the ANSI C/POSIX library
functions that makes them `safe' against races and snooping when used
in the `default' case, and that don't require per-user frobbing of the
filesystem namespace.  That seems more sensible than trying to update
all software in the known universe to use mkstemp().