tmpnam warning saying it is dangerous

Question

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).

Solution 1

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.

Solution 2

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?

Solution 3

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).

Solution 4

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.

View more solutions

Comments

[janneb]

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.

[James Curran]

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)

[usr1234567]

Using mktemp is Unix-only for Windows you need tmpnam_s and _wtmpnam_s. Thus a platform-independent version is not that easy.