[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: severity for bugs in ignoring TMP/TMPDIR?



Paul Wise <pabs@debian.org> writes:
> On Mon, Feb 13, 2012 at 11:29 PM, Jon Dowland wrote:

>> If $TMPDIR is not set, /tmp is a reasonable default, so I'd expect a
>> *lot* of matches for '/tmp' in programs with correct behaviour.

> I get the impression that directly hardcoding /tmp/ usually indicates
> that safe temporary file/dir functions are not being used. Usually there
> isn't any point in hardcoding /tmp/ if you are using those functions,
> since they respect TMPDIR and fall back on /tmp/ anyway.

I think this is incorrectly optimistic about the existence of general and
secure functions for creating temporary files that handle TMPDIR.  In C,
for example, the only portable and secure way to create a temporary file
is mkstemp, which does not handle TMPDIR vs. /tmp for you and requires
that you handle it yourself.

tempnam() handles TMPDIR, but it's very difficult to use properly (which
is why the man page says "never use this function").  tmpfile() is secure,
but is not documented as supporting TMPDIR and creates an unlinked file,
so you can't use it for some things you need to use a temporary filel for.
All the other options are worse.

Your statement is correct about shell, where mktemp does the right thing,
but you'd have to look at each language separately.  Most of the scripting
languages probably have some facility to do the right thing; compiled
languages I suspect are a bit more variable.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: