NAME
tempnam,
tmpfile,
tmpnam
—
temporary file routines
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <stdio.h>
FILE *
tmpfile(
void);
char *
tmpnam(
char
*str);
char *
tempnam(
const
char *tmpdir,
const char
*prefix);
DESCRIPTION
The
tmpfile() function returns a pointer to a stream
associated with a file descriptor returned by the routine
mkstemp(3). The created file is
unlinked before
tmpfile() returns, causing the file to be
automatically deleted when the last reference to it is closed. The file is
opened with the access value ‘
w+
’.
The
tmpnam() function returns a pointer to a file name, in the
P_tmpdir
directory, which did not reference an
existing file at some indeterminate point in the past.
P_tmpdir
is defined in the include file
<stdio.h>. If the argument
s is non-
NULL
, the file name is
copied to the buffer it references. Otherwise, the file name is copied to a
static buffer. In either case,
tmpnam() returns a pointer to
the file name.
The buffer referenced by
s is expected to be at least
L_tmpnam
bytes in length.
L_tmpnam
is defined in the include file
<stdio.h>.
The
tempnam() function is similar to
tmpnam(), but provides the ability to specify the directory
which will contain the temporary file and the file name prefix.
The environment variable
TMPDIR
(if set), the argument
tmpdir (if non-
NULL
), the
directory
P_tmpdir
, and the directory
/tmp are tried, in the listed order, as directories in which
to store the temporary file.
The argument
prefix, if non-
NULL
,
is used to specify a file name prefix, which will be the first part of the
created file name.
tempnam() allocates memory in which to
store the file name; the returned pointer may be used as a subsequent argument
to
free(3).
RETURN VALUES
The
tmpfile() function returns a pointer to an open file
stream on success, and a
NULL
pointer on error.
The
tmpnam() and
tempnam() functions return
a pointer to a file name on success, and a
NULL
pointer on error.
ERRORS
The
tmpfile() function may fail and set the global variable
errno for any of the errors specified for the library
functions
fdopen(3) or
mkstemp(3).
The
tmpnam() function may fail and set
errno for any of the errors specified for the library
function
mktemp(3).
The
tempnam() function may fail and set
errno for any of the errors specified for the library
functions
malloc(3) or
mktemp(3).
SEE ALSO
mkstemp(3),
mktemp(3)
STANDARDS
The
tmpfile() and
tmpnam() functions conform
to
ANSI X3.159-1989 (“ANSI C89”). All
described functions also conform to
IEEE Std 1003.1-2001
(“POSIX.1”), albeit the
tempnam() and
tmpnam() functions have been marked as obsolete in the
IEEE Std 1003.1-2008 (“POSIX.1”) revision.
BUGS
These interfaces are provided for
AT&T System V
UNIX and ANSI compatibility only. The
mkstemp(3) interface is
strongly preferred.
SECURITY CONSIDERATIONS
There are four important problems with these interfaces (as well as with the
historic
mktemp(3) interface).
First, there is an obvious race between file name selection and file creation
and deletion: the program is typically written to call
tmpnam(),
tempnam(), or
mktemp(3). Subsequently, the
program calls
open(2) or
fopen(3) and erroneously opens a
file (or symbolic link, or fifo or other device) that the attacker has placed
in the expected file location. Hence
mkstemp(3) is recommended,
since it atomically creates the file.
Second, most historic implementations provide only a limited number of possible
temporary file names (usually 26) before file names will start being recycled.
Third, the
AT&T System V UNIX implementations
of these functions (and of
mktemp(3)) use the
access(2) system call to
determine whether or not the temporary file may be created. This has obvious
ramifications for setuid or setgid programs, complicating the portable use of
these interfaces in such programs. Finally, there is no specification of the
permissions with which the temporary files are created.
This implementation of
tmpfile() does not have these flaws,
and that of
tmpnam() and
tempnam() only
have the first limitation, but portable software cannot depend on that. In
particular, the
tmpfile() interface should not be used in
software expected to be used on other systems if there is any possibility that
the user does not wish the temporary file to be publicly readable and
writable.
A link-time warning will be issued if
tmpnam() or
tempnam() is used, and advises the use of
mkstemp() instead.