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 _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
