Re: [Nmh-workers] Re: Diffs for replacing mktemp() usage

[Valdis . Kletnieks]

On Tue, 02 Feb 2010 21:38:20 CST, Earl Hood said:

> If the calling code did not immediately use the temp file,
> the new functions close the descriptor returned from mkstemp(),
> but it does NOT delete the file.
> 
> Since the file still exists, an external (different uid) process
> cannot create one in its place, so the race condition vulnerability
> does not exist.  The file is just sitting there.

Unfortunately, this is only true if the directory you're creating the file
in isn't writable by other processes - in other words, doing this in /tmp
isn't safe, but doing a 'umask 077; mkdir /tmp/$USER' and then
creating /tmp/$USER/$TMPNAME is safe. Sticky bit on the directory helps too,
but we probably should program defensively and get it right even if the
sysadmin failed to do so.

Otherwise, you're still open to a race condition - an attacker can just
rename the file you created, and then stick another file or even a symlink
in place of the old name:

% ls -ld /tmp/foo
drwxrwxrwx. 2 root root 4096 Feb  3 09:30 /tmp/foo
% ls -l /tmp/foo
total 0
-rw-r--r--. 1 root root 0 Feb  3 09:30 bar
% mv /tmp/foo/bar /tmp/foo/baz
% ls -l /tmp/foo
total 0
-rw-r--r--. 1 root root 0 Feb  3 09:30 baz
% touch /tmp/foo/bar
% ls -l /tmp/foo
total 0
-rw-r--r--. 1 valdis valdis 0 Feb  3 09:31 bar
-rw-r--r--. 1 root   root   0 Feb  3 09:30 baz

pgp0OfPRrxETL.pgp
Description: PGP signature