git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Paul Jackson <pj@sgi.com>
Cc: Petr Baudis <pasky@ucw.cz>, git@vger.kernel.org, mj@ucw.cz
Subject: Re: fix mktemp (remove mktemp ;)
Date: Sat, 16 Apr 2005 20:33:25 -0400	[thread overview]
Message-ID: <20050417003325.GA15608@redhat.com> (raw)
In-Reply-To: <20050416170221.38b3e66c.pj@sgi.com>

On Sat, Apr 16, 2005 at 05:02:21PM -0700, Paul Jackson wrote:
 > > And racy. And not guaranteed to come up with fresh new files.
 > 
 > In theory perhaps.  In practice no.
 > 
 > Even mktemp(1) can collide, in theory, since there is no practical way
 > in shell scripts to hold open and locked the file from the instant of it
 > is determined to be a unique name.

Using the pid as a 'random' number is a bad idea. all an attacker
has to do is create 65535 symlinks in /usr/tmp, and he can now
overwrite any file you own.

mktemp is being used here to provide randomness in the filename,
not just a uniqueness.

 > The window of vulnerability for shell script tmp files is the lifetime
 > of the script - while the file sits there unlocked.  Anyone else with
 > permissions can mess with it.

Attacker doesnt need to touch the script. Just take advantage of
flaws in it, and wait for someone to run it.

 > More people will fail, and are already failing, using mktemp than I have
 > ever seen using $$ (I've never seen a documented case, and since such
 > files are not writable to other user accounts, such a collision would
 > typically not go hidden.)
 > 
 > Fast, simple portable solutions that work win over solutions with some
 > theoretical advantage that don't matter in practice, but also that are
 > less portable or less efficient.

I'd suggest fixing your distributions mktemp over going with an
inferior solution.

		Dave


  reply	other threads:[~2005-04-17  0:29 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-16 23:27 [PATCH] fix mktemp (remove mktemp ;) Paul Jackson
2005-04-16 23:27 ` [PATCH] missing mkdir -p flag in gitdiff-do Paul Jackson
2005-04-16 23:28 ` [PATCH] optimize gitdiff-do script Paul Jackson
2005-04-16 23:43   ` Petr Baudis
2005-04-17  0:10     ` Paul Jackson
2005-04-18 15:23       ` Paul Jackson
2005-04-18 18:30         ` Petr Baudis
2005-04-18 19:17           ` Paul Jackson
2005-05-10  2:56           ` Paul Jackson
2005-04-16 23:36 ` [PATCH] fix mktemp (remove mktemp ;) Jan-Benedict Glaw
2005-04-16 23:46   ` Paul Jackson
2005-04-16 23:37 ` Petr Baudis
2005-04-17  0:02   ` Paul Jackson
2005-04-17  0:33     ` Dave Jones [this message]
2005-04-17  0:44       ` Paul Jackson
2005-04-17  0:57         ` Dave Jones
2005-04-17  1:03           ` David Lang
2005-04-17  1:15           ` Paul Jackson
2005-04-17  2:38         ` Brian O'Mahoney
2005-04-17  2:46           ` Paul Jackson
2005-04-17  0:51       ` Erik van Konijnenburg
2005-04-17  1:18         ` Paul Jackson
2005-04-18  3:01     ` Herbert Xu
2005-04-18  4:47       ` Paul Jackson
2005-04-18 12:12       ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050417003325.GA15608@redhat.com \
    --to=davej@redhat.com \
    --cc=git@vger.kernel.org \
    --cc=mj@ucw.cz \
    --cc=pasky@ucw.cz \
    --cc=pj@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).