Jonathan Stone writes:
> >> setuid/setgid *is* the concern here, isn't it?
  
> darren reed writes:
> >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.
> 
> 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.

(see below)
  
> 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?

I can't remember enough about whether the semantics of O_EXCL|O_CREAT
differ for NFS as for UFS, but as you probably know, use of O_EXCL
with O_CREAT prevents people from playing symlink games.

The original reason for the link time warning in mktemp()/tempnam()/tmpnam() 
was because a lot of programs use fopen() on the temp file, which
doesn't use O_EXCL, or they were using open() without O_EXCL. This is
the cause of most of the holes that can be raced.

mkstemp() does use O_EXCL. This prevents the symlink race. tmpfile()
uses mkstemp(), so it's safe too. The reference in the tmpnam(3) man
page about the use of mkstemp() is specifically for tmpfile().
Also, that man page suggests use of mkstemp() use not mktemp().


> Could you indulge me, and show a scenario where using mkstemp()
> instead of mktemp() really helps?  If it does, then

(see above)

> 	a) I'll update the manpage accordingly, and

Already done (for mktemp() that is - tmpnam() et al already has it).

> 	b) look into  a mkstmpdir() for programs like df, that
> 	   use mktemp()  to create names for `temporary' directories.

May be a good idea. or just hack df to use _mktemp() (1/2 :-)