Re: [Nmh-workers] Re: Diffs for replacing mktemp() usage

[Earl Hood]

On Wed, Feb 3, 2010 at 12:30 PM,  <address@hidden> wrote:

>> If the calling code did not immediately use the temp file,
>> the new functions close the descriptor returned from mkstemp(),
>> but it does NOT delete the file.
>>
>> Since the file still exists, an external (different uid) process
>> cannot create one in its place, so the race condition vulnerability
>> does not exist.  The file is just sitting there.
>
> Unfortunately, this is only true if the directory you're creating the file
> in isn't writable by other processes - in other words, doing this in /tmp
> isn't safe,

Standard procedure is to have the sticky-bit set
on the system temp directory, so any files created
in it can only be deleted/accessed by the owner (or
root).

But, yes, there are probably some f'ed up configurations
out there.

>but doing a 'umask 077; mkdir /tmp/$USER' and then
> creating /tmp/$USER/$TMPNAME is safe. Sticky bit on the directory helps too,
> but we probably should program defensively and get it right even if the
> sysadmin failed to do so.

Agree with philosophy, but the directory method does
complicate cleanup, which requires more work.

A descision to be made is the work I have currently
done worth rejecting because it fails to address all
(less probable) cases, or accept it now for something
better than what currently exists and then improve
upon it later?

Since it has been years that nmh has existing with
temporary file problem with no one fixing (a couple have
tried and realized the worked involved so backed out),
I think if there is any improvement to the current code
base, it is worth accepting.

> Otherwise, you're still open to a race condition - an attacker can just
> rename the file you created, and then stick another file or even a symlink
> in place of the old name:
>
> % ls -ld /tmp/foo
> drwxrwxrwx. 2 root root 4096 Feb  3 09:30 /tmp/foo

If you own the box, fix it.  If not, complain to
the sys admin.

All my boxes have /tmp permissions set correctly,
and it seems to be that way for stock Linux distros.
Unsure about other unices out there, but I do remember
many years ago having to fix /tmp permissions on
solaris systems.

Note, as of now, my latest changes default to user's
mail dir for temp files.  I'm not concerned about
NFS, unless, there is some programs in nmh that
are using temp files for locking/semaphore purposes.

I do not use rcvstore, and related programs, so maybe
someone can chime in if these programs use lock files
or not.  I can look at the code later, but I would
like input from those that use such programs.

--ewh