From owner-freebsd-hackers  Fri Oct 18 18:16:00 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id SAA07691
          for hackers-outgoing; Fri, 18 Oct 1996 18:16:00 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA07677
          for <freebsd-hackers@FreeBSD.org>; Fri, 18 Oct 1996 18:15:56 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id LAA27084; Sat, 19 Oct 1996 11:15:27 +1000
Date: Sat, 19 Oct 1996 11:15:27 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199610190115.LAA27084@godzilla.zeta.org.au>
To: bde@zeta.org.au, tridge@arvidsjaur.anu.edu.au
Subject: Re: fix for symlinks in /tmp (fwd) FYI
Cc: freebsd-hackers@FreeBSD.org, Guido.vanRooij@nl.cis.philips.com,
        julian@whistle.com
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>> Our mkstemp() and mktemp() use O_EXCL, and gcc seems to use mktemp(),
>> so I think gcc isn't vulnerable.
>
>Really? mktemp() actually creates the file? I thought that was what
>tmpfile() was for.

Oops.  I forgot that mktemp() was so braindamaged.

>ahhh, ok, mktemp() calls:
>
>   _gettemp(char *path,int *doopen)
>
>and the doopen parameter controls if the open is used to create it
>with O_EXCL set. mktemp() looks like this:
>
>char *
>mktemp(path)
>        char *path;
>{
>        return(_gettemp(path, (int *)NULL) ? path : (char *)NULL);
>}
>
>so doopen is set to NULL, meaning don't create. This means anyone
>using mktemp() still needs to be careful about setting O_EXCL. Does
>gcc on BSD do this? 

Not in FreeBSD.

There is still a race (with a much smaller window) if O_EXCL isn't
used even if symlinks aren't followed.

Bruce