Re: mktemp() and friends

[avalon () coombs anu edu au (Darren Reed)]

In some mail from Theo de Raadt, sie said:
> > mktemp/mkstemp/tmpnam/tempnam should not be used and tmpfile should be
> > implemented as above.
>
> Sigh.
>
> You say mkstemp shouldn't be used, eh?

Sorry, I didn't have either a man page or .c for it when I sent that
e-mail.  Life's tough.

> My thesis of late has been that 90% of security errors has been
> because the programmers don't know their API's.  Mainly I'm talking
> about strncpy and strncat, but... this one is also relevant.
>
> I suggest you read libc/stdio/mktemp.c to see that mkstemp() is in
> fact safe and does use O_CREAT|O_EXCL as you suggested.  The man page
> also says that it is safe.  mkstemp() was added precisely because of
> the problem you describe.
>
> mkstemp() _is_ safe, and should be used wherever possible.  That's what
> I said earlier today, isn't it?

Quite, but that isn't the point I was trying to make...

Some man pages you can buy today say:
mktemp(3C) -
    Remarks:
      These functions are provided solely for backward compatibility and
      importability of applications, and are not recommended for new
      applications where portability is important.  For portable
      applications, use tmpfile() instead (see tmpfile(3S)).

Solaris2 doesn't have a mkstemp (Solaris1 does).

Both do have tmpfile(3S).  Why do we need so many variants of this
function and provide people writing software with more chances to
make bad decisions when cutting code ?

The point being, tmpfile/mkstemp should be the only public interfaces for
this functionaliy, and although mktemp/tmpnam appear to provide useful
features, they're insecure.

Has OpenBSD taken the next step and removed mktemp/tmpnam since they're
no longer needed (even if just documentation for them) to discourage
new use of them ?

Darren