Subject: Re: mktemp() warning lossage?
To: Darren Reed <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 03/24/1997 01:22:22
[Moving a thread about mktemp() vs mkstemp() warnings to here
Darren reed writes:
>>In some mail I received from Jonathan Stone, sie wrote
>> setuid/setgid *is* the concern here, isn't it?
>It is _one of_ the concerns. For example, if a user is running a program
>that creates a temp file in /tmp and I can predict it happening (i.e. cron
>jobs or quiet system), I can have a good chance at creating a symlink to
>some other file they own, say .rhosts. This may then have its mode
>changed and contents trashed with something that creates a security
The warnings in question simply advise using mkstemp(), instead of
mktemp() or tmpnam() and its friends.
Given the shared implementation, I'm afraid I don't see how NetBSD's
mktemp() and mkstemp() (or even tmpnam(), for that matter) differ in
any meaningful way, w.r.t that particular security risk.
I may be missing something about the semantics of open() with
O_EXCL|O_CREAT, but _in general_ (e.g., diskless workstations, or
small-disk machines with TMPDIR mounted over NFS) I don't see how
mkstemp() really stops sniffing tempfiles or kludging up symlinks. In
fact, I thought that was part of the justification for the recent
proposal for a per-user /tmp filesystem?
Could you indulge me, and show a scenario where using mkstemp()
instead of mktemp() really helps? If it does, then
a) I'll update the manpage accordingly, and
b) look into a mkstmpdir() for programs like df, that
use mktemp() to create names for `temporary' directories.