Re: tmpnam vs mkstemp, was Re: [Exim] Problem with compiling…

Top Page
Delete this message
Reply to this message
Author: Ian Jackson
Date:  
To: exim-users, dwheeler
Subject: Re: tmpnam vs mkstemp, was Re: [Exim] Problem with compiling exim-3.22 on Linux
Jim Knoble writes ("Re: tmpnam vs mkstemp, was Re: [Exim] Problem with compiling exim-3.22 on Linux"):
> Circa 2001-Mar-30 09:25:46 +0100 dixit Philip Hazel:
> : What is wrong with tmpfile()? (It is in the C standard.)
>
> It's not guaranteed to be implemented so as to avoid race conditions.
> For one take on this, see
>
> http://www.linuxdoc.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html
>
> section 6.8.1.2 "Temporary Files".


I quote:

According to the 1997 ``Single Unix Specification'', the preferred
method for creating an arbitrary temporary file is tmpfile(3). The
tmpfile(3) function creates a temporary file and opens a
corresponding stream, returning that stream (or NULL if it
didn't). Unfortunately, the specification doesn't make any guarantees
that the file will be created securely, and I've been unable to
assure myself that all implementations do this
securely. Implementations of tmpfile(3) should securely create such
files, of course, but it's difficult to recommend tmpfile(3) because
there's always the possibility that a library implementation fails to
do so. This illustrates a more general issue, the tension between
abstraction (which hides ``unnecessary'' details) and security (where
these ``unnecessary'' details are suddenly critical). If I could
satisfy myself that tmpfile(3) was trustworthy, I'd use it, since
it's the simplest solution for many situations.

This is completely absurd, of course. An implementation of tmpfile()
which does *not* create the file in the right way cannot safely be
used by *any* program.

Therefore the spec of tmpfile() must include that requirement, whether
or not it's stated in POSIX or anywhere else. Furthermore, tmpfile()
is widely used, so if it is broken on your system then nearly
everything on the system will be broken and you have no hope of
security.

So the answer is: use tmpfile() and if this introduces a security hole
get your OS vendor to fix it, or fix it yourself[1].

Phil: if you're worried about being blamed for crap libcs, make an
autoconf test that spots if tmpfile is broken and makes the build fail
if it is. I'll have a go at writing you one if you like.

Ian.

[1] If your OS vendor won't and you don't have the source code, get a
better OS vendor.