Subject: Re: mktemp() warning lossage?
To: None <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
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().