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

[Earl Hood]

The changes I've made do not contain the same security flaw
that has been noted, from what I understand.

The old, insecure, mktemp() does NOT create a file.  All
it does is provide a temporary filename, that (at-the-time)
does not exist.  Therefore, when using it, there is a
race condition between the function returns and when the
caller decides to create the file.

mkstemp() actually creates the file and returns a file descriptor
for it (along with modifying template to the pathname of the file).
Therefore, there is no race condition and the reason one should
use mkstemp().

Where I noticed that calling code was to use the open descriptor
(either the unix fd or the standard C FILE *), I modified the code
to use what is returned from the new functions (the new functions
will call fdopen() on the descriptor if FILE* is desired).

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.

When the nmh code gets around to using the temporary file, the call
to open/fopen basically re-opens the file.  This does increase the
window that if the main program is terminated abnormally, a temporary
file can be left around, but that already is a problem when you have
an application that calls other components via exec() and nmh has
not had a chance to call unlink().

Someone please correct me if I my understanding of mktemp()
and mkstemp() is wrong?

--ewh