[MINC-development] patches for tmpnam

[Steve ROBBINS]

On Thu, Mar 06, 2003 at 02:25:28PM -0500, Vicka Corey wrote:
 
> Fixing race condition and leaks is worth doing too, of course, but 
> please don't minimize the need for code to compile cleanly.  

Vicka, I apologize for a poor choice of words.  I did not mean to
minimize the request.
 
> Did the tmpnam() and tempnam() calls in the code clean up after themselves?
> If so, the same closes should still work; if not it is at least no worse.

The difference is that tmpnam() and tempnam() do not open files.

 
> > P.P.S. The man page for mkstemp() on my system says "Don't use this function,
> > use tmpfile(3) instead.  It is better defined and more portable."
> 
> Under gcc 3.1, the tmpfile() man page says,
> BUGS
>      These interfaces are provided for System V and ANSI compatibility only.
>      The mkstemp(3) interface is strongly preferred.

Amusing.  I think both tmpfile() and mkstemp() are in POSIX now, anyway,
so it probably doesn't matter which is used.
 

On Thu, Mar 06, 2003 at 03:10:40PM -0500, Robert VINCENT wrote:
 
> This partially fixes the race condition, since the central issue with
> tempnam() is that it doesn't actually create a file, whereas mkstemp()
> creates a zero-length file with the permissions 600.  I think it is
> therefore much harder for an attacker to exploit mkstemp() than tempnam().

Yes, mkstemp() completely fixes the race condition.  Not that I'm particularly
worried about race conditions in MINC code.

-S