|TMPNAM(3)||Library Functions Manual||TMPNAM(3)|
tmpnam — temporary file
char *tmpdir, const char
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
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
str is non-null, the file name is copied to the buffer
it references. Otherwise, the file name is copied to a static buffer. In
tmpnam() returns a pointer to the file
The buffer referenced by str is expected to
be at least
L_tmpnam bytes in length.
L_tmpnam is defined in the include file
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.
allocates memory in which to store the file name; the returned pointer may
be used as a subsequent argument to
tmpfile() function returns a pointer
to an open file stream on success, and a null pointer on error.
tempnam() functions return a pointer to a file name
on success, and a null pointer on error.
tmpnam() function may fail and set
errno for any of the errors specified for the library
tmpnam() functions conform to ANSI
X3.159-1989 (“ANSI C89”).
tempnam() are provided for System V and ANSI
compatibility only. These interfaces are typically not used in safe ways.
The mkstemp(3) interface is
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
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 System V implementations of these functions (and of mktemp(3)) use the access(2) function to determine whether or not the temporary file may be created. This has obvious ramifications for daemons or setuid/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 does not have these flaws, but portable software cannot depend on that.
For these reasons,
ld(1) will output a warning
message whenever it links code that uses the functions
|August 30, 2019||OpenBSD-7.0|