[Moving a thread about mktemp() vs mkstemp() warnings to here
 from elsewhere]



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
>problem.


hi Darren,

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.