Re: Question on using /tmp

From: Floyd L. Davidson (
Date: 06/20/05

Date: Sun, 19 Jun 2005 20:37:45 -0800

Shi Jin <> wrote:
>Hi there,
>In my C code, I need to make a system call to a command to generate a
>temporary file and my code is going to read something out of it.
>I cannot use the pipes to redirect the output to stdout since it varies
>from machine to machine. Only when I call the command in the form
>tsm -Loutput.file
>The command "tsm" will give me a well formated file output.file.
>I want to make output.file a temporary file so that I can use the function
>tmpnam or tmpfile.
>I guess using tmpfile is better in the sense it generates a unique
>filename in the same time creates the file. But I have to use tmpnam since
>I need to create the file in another way. Now my code looks like

Does your "tsm" command have any way to generate output to
stdout? Usually that would be done with either no output file
name specified, or by using "-" as the output name. Hence you
might be able to use

   popen("tsm -L-");

>When I compile it, I get the following warnings:
>warning: the use of `tmpnam' is dangerous, better use `mkstemp'
>For the same reason above, I cannot use mkstemp either. I could use mktemp
>which makes to difference to me compared to tmpnam.
>But still, as the warning said, there is some danger in using tmpnam
>although it seldom happens.
>I wonder if there is a perfect solution to this.
>Thank you very much

Using a temporary name, there probably is no "perfect" solution.
However, you can avoid some of the problems from tmpnam() and
mktemp() functions. That depends on just how many temporary
files you are going to be opening, and what your security
requirements are.

>From the sound of it, there is only one temp file being opened,
hence you are not worried about stepping on your own feet within
the program. You could, for example, use the PID to generate a
file name. Other instances of your program will not have the
same PID. Or you could use that plus some part of a randomized
number to also make it difficult for another program to predict.

It depends on what kind of security you are trying to implement,
and just who you are securing this against. (The above random
number is not really secure unless you use a exceedingly long
file name.)

Regardless of how you choose a name though, you want to unlink(2)
the name as soon as you have opened it:


The effect is to remove the name (from sight) in a public
directory. It is then impossible for another process to open
it, but your process can read and write to an unnamed file until
such time as fclose(fp) is called.

I'm not sure how effective it would actually be, but if you are
concerned about another process being able to intercept the
filename between fopen() and the call to unlink(), it might be
useful to put a nanosleep() command immediately prior to
fopen(). That will cause the process to give up its timeslice,
and insure that the call to fopen() happens as the first
operation in a new timeslice, which hopefully will not result in
any delay that causes another context switch before unlink() is
called. That's about as close to atomic as it will get without
using a real time OS.

Floyd L. Davidson           <>
Ukpeagvik (Barrow, Alaska)