Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by krbdev.mit.edu (8.12.9) with ESMTP id m6I3rCo4001515; Thu, 17 Jul 2008 23:53:12 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m6I3r65n017534 for <rt@krbdev.MIT.EDU>; Thu, 17 Jul 2008 23:53:06 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m6I3r6WA018811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rt@krbdev.MIT.EDU>; Thu, 17 Jul 2008 23:53:06 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m6I3r6Y7025199; Thu, 17 Jul 2008 23:53:06 -0400 (EDT)
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6002] krb5_rc_io_creat should use mkstemp
References: <rt-6002-27544.17.3618949443514@krbdev.mit.edu>
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 17 Jul 2008 23:53:05 -0400
In-Reply-To: <rt-6002-27544.17.3618949443514@krbdev.mit.edu> (Ken Raeburn via's message of "Thu, 17 Jul 2008 23:24:08 -0400 (EDT)")
Message-ID: <ldviqv3vof2.fsf@cathode-dark-space.mit.edu>
Lines: 20
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-BY: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
RT-Send-Cc: 
X-RT-Original-Encoding: us-ascii
Content-Length: 1020

"Ken Raeburn via RT" <rt-comment@krbdev.mit.edu> writes:

> Coming up with names not already taken isn't all that hard, it just  
> requires setting up a loop and having a reasonably large space of  
> names to work through.  With a large enough namespace and a halfway  
> decent PRNG, we ought to be able to find an unused name in one or two  
> tries, actually: dir + "/krb5_RC" + base64(random).

We already have a mkstemp() replacement in the tree, it seems, but
only use it when the system does not already have mkstemp().

> Do we have this sort of thing happening elsewhere, such that a utility  
> function mkstemp_mode_0600 would help?

It looks like recent BSD-derived implementations of mkstemp() use mode
0600, but POSIX does not guarantee this.  We could call mkstemp() and
then fstat() to make sure we got the modes we expect, and if we get
modes we do not expect, fall back on something more irritating.  (Or
do autoconf run-time tests to see if mkstemp() is sane, but I'd rather
not do run-time tests.)