This is the mail archive of the
mailing list for the glibc project.
Re: tmpnam v mkstemp
- To: Paul Eggert <eggert at twinsun dot com>
- Subject: Re: tmpnam v mkstemp
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Sat, 11 Nov 2000 20:04:15 -0800 (PST)
- cc: geoffk at redhat dot com, Neale dot Ferguson at softwareAG-usa dot com, libc-alpha at sources dot redhat dot com
On Sat, 11 Nov 2000, Paul Eggert wrote:
> > It is a libc link-time warning.... use of tmpnam() can allow another user
> > to overwrite files owned by the user running tmpnam() even if the
> > other user cannot write to those files.
> No, you can use `tmpnam' safely by opening the returned file name with
> O_CREAT|O_EXCL. This is similar to what `mkstemp' does internally.
> I've seen applications that do this for portability reasons, as
> `mkstemp' is not universally supported.
I don't know what I was thinking when I wrote *my* reply to that. I was
rushing out the door. :)
There is no reason why a filename generated by tmpnam() should clash with
another name generated by the same function in another process. The process ID
of the caller can be recorded in the temporary name, and if need be, some
machine identifier, like the hardware address from a network adapter, making it
just short of impossible for another currently running process on the same
machine or another machine to accidentally take the same name through tmpnam().
So the O_EXCL shouldn't even be required if the filename generation method is
> Does libc also warn about the use of functions like `strcpy' and
> `gets' at link time? They are security holes as well, if used
It does about the latter, justifiably so because there are very few
circumstances in which gets can be used in a robust program. Basically, the
input to gets() has to be under software control rather than coming
directly from the world; e.g. an assembler could use gets() to read lines out
output from a compiler which knows about the assembler's limitation and never
exceeds it. That's actually good example; I've seen assemblers which would
crash if given an illegal opcode. This only impeded their use for assembly
language programming, rather than the intended use as a compiler back end.