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 m6I38so4001470; Thu, 17 Jul 2008 23:08:54 -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 m6I38mtH004159 for <rt@krbdev.MIT.EDU>; Thu, 17 Jul 2008 23:08:48 -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 m6I38mBj015595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rt@krbdev.MIT.EDU>; Thu, 17 Jul 2008 23:08:48 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m6I38mtl024980; Thu, 17 Jul 2008 23:08:48 -0400 (EDT)
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6002] krb5_rc_io_creat should use mkstemp
References: <rt-6002-27539.0.0123977007292808@krbdev.mit.edu>
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 17 Jul 2008 23:08:47 -0400
In-Reply-To: <rt-6002-27539.0.0123977007292808@krbdev.mit.edu> (Ken Raeburn via's message of "Thu, 17 Jul 2008 20:47:57 -0400 (EDT)")
Message-ID: <ldvod4vvqgw.fsf@cathode-dark-space.mit.edu>
Lines: 18
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: 756

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

> With fchmod, we would have a race condition where some other party  
> could open the file after it was created but before the fchmod call.   
> In the normal UNIX model, fchmod does not revoke access to an already  
> opened file.

Ok, so this is a case where using mkstemp() is clearly less safe.
What should we do?  tmpnam() and open(O_CREAT|O_EXCL)?  Some
development environments are evolving toward warning about uses of
mktemp(), which is similar to tmpnam(), so they may also flag uses of
tmpnam().

We could use umask(), but while we could lock around it, we could not
guarantee that the application would not call umask() outside of our
locks.

I'm going to revert this change for now.