tags:

views:

100

answers:

5

I get this warning saying that tmpnam is dangerous, but I would prefer to use it, since it can be used as is in Windows as well as Linux. I was wondering why it would be considered dangerous (I'm guessing it's because of the potential for misuse rather than it actually not working properly).

Thanks in advance!

+4  A: 

From tmpnam manpage :


The tmpnam() function generates a different string each time it is called, up to TMP_MAX times. If it is called more than TMP_MAX times, the behavior is implementation defined.

Although tmpnam() generates names that are difficult to guess, it is nevertheless possible that between the time that tmpnam() returns a pathname, and the time that the program opens it, another program might create that pathname using open(2), or create it as a symbolic link. This can lead to security holes. To avoid such possibilities, use the open(2) O_EXCL flag to open the pathname. Or better yet, use mkstemp(3) or tmpfile(3).


Mktemp really create the file, so you are assured it works, whereas tmpnam returns a name, possibly already existing.

Scharron
+1  A: 

From the tmpnam(3) manpage:

Although tmpnam() generates names that are difficult to guess, it is nevertheless possible that between the time that tmpnam() returns a pathname, and the time that the program opens it, another program might create that path‐ name using open(2), or create it as a symbolic link. This can lead to security holes. To avoid such possibili‐ ties, use the open(2) O_EXCL flag to open the pathname. Or better yet, use mkstemp(3) or tmpfile(3).

janneb
A: 

if you speak about the compiler warning of MSVC:

 These functions are deprecated because more secure versions are available;
 see tmpnam_s, _wtmpnam_s.

(http://msdn.microsoft.com/de-de/library/hs3e7355(VS.80).aspx)

otherwise just read what the manpages say about the drawbacks of this function. it is mostly about a 2nd process creating exactly the same file name as your process just did.

akira
+1  A: 

If you want to use the same symbol on multiple platforms, use a macro to define TMPNAM. As long as you pick more secure functions with the same interface, you'll be able to use it on both. You have conditional compilation somewhere in your code anyway, right?

Nathon
A: 

The function is dangerous, because you are responsible for allocating a buffer that will be big enough to handle the string that tmpnam() is going to write into that buffer. If you allocate a buffer that is too small, tmpnam() has no way of knowing that, and will overrun the buffer (Causing havoc). tmpnam_s() (MS's secure version) requires you to pass the length of the buffer, so tmpnam_s know when to stop.

James Curran
There is a pre-processor constant L_tmpnam which specifies the maximum length the implementation will write (or in a single-threaded program, you can use a NULL pointer in which case it will use a static buffer). Thus it's a problem easily avoided. The dangerous part comes from the possible race condition between creating the file name, and subsequently creating the file itself.
janneb
Most security holes are easy to avoid. (Your answer cites an easy way to avoid the problem you describe). THe problem I describe is more likely to *happen* if you don't follow the rules. (it's also the problem fixed by tmpnam_s(), so it's clearly the problem they were thinking of)
James Curran