[darcs-devel] security question about msktemp

[David Roundy]

On Sat, Apr 16, 2005 at 08:30:16PM +0300, Aggelos Economopoulos wrote:
> On Saturday 16 April 2005 17:34, David Roundy wrote:
> > This is a question for people who know better than me about security
> > issues.
> >
> > Is it unstafe to close the file descriptor that is returned by mkstemp,
> > and instead just reopen the file based on the filename mkstemp returns?
> 
> It depends on what directory it's created in. I'll refer you to
> 
> http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html#TEMPORARY-FILES
> 
> for details, instead of giving a short but incomplete answer.

Thanks.  It looks like as long as our files are being created in a
non-world-sticky-writeable directory we're okay, but the moment we start
respecting TMPDIR (or choosing /tmp by default) we start getting in
trouble if we ever trust a filename.

On the other hand, we currently create our temporary files in the current
directory, which isn't really subject to these races.  On the third hand,
creating temporaries in the working directory can be annoying...

The temporary *directories* on the other hand, are created in /tmp (or in
$TMPDIR), which is more risky.  Perhaps we should stick everything by
default in _darcs/tmp/, and only respect DARCS_TMPDIR if it's defined (and
document that it mustn't be a shared directory like /tmp or /var/tmp).
This is against the recommendation, but I'd rather not have to deal with
these security issues.  The whole tmp-cleaner set of holes looks like a
downright nightmare.

In any case, given our current usage (mkstemp always creates files in the
current directory), it seems like we could stop trying to do everything
with the file descriptor.  In practice, most of the time we create a
temporary file, it's to pass as a flag to another program anyways (e.g. an
editor), where there doesn't seem to *be* a secure solution involving /tmp.
-- 
David Roundy
http://www.darcs.net