Re: fix mktemp (remove mktemp ;)
- From
- Dave Jones <davej@redhat.com>
- Date
- Apr 17, 2005, 00:33 UTC
- Message-ID
- <20050417003325.GA15608@redhat.com>
- 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