Justin,
> > > tmpnam.3 (and tmpnam_r.3)
> > > I think this is one of the classically-buggy functions. Since it
> > > generates a filename, but doesn't ask the kernel to create that file
> > > atomically, it is easy to pass its return value to fopen() and be
> > > done
> > > with it; but, again, this is insecure if you don't use "exclusive"
> > > mode. It should be fine if you do use it, though.
> >
> > No! The problem is that between creation of the name and opening
> > it (in /tmp, a world writable directory), some other program could
> > create that file or create it as a symlink, causing the original
> > program to do the wrong thing.
> Not in exclusive mode.. In my test it didn't matter if it was a
> dangling symlink, a real symlink, or a file. Exclusive mode fails if
> the pathname exists in any way:
<blush> Yes, you are right. I should have read and thought harder
before I wrote that... My apologies.
In 2.34, the tmpnam.3 man page will include the following
para:
Although tmpnam(3) generates names that are difficult to
guess, it is nevertheless possible that between the time
that tmpnam(3) returns a pathname, and the time that the
program opens it, another program might create that pathnam
using open(2), or create it as a symbolic link. This can
lead to security holes. To avoid such possibilities, use
the open(2) O_EXCL flag to open the pathname. Or better
yet, use mkstemp(3) or tmpfile(3).
I added similar text to temnam.3.
I also removed the text "POSIX dictates tmpnam(3)" from mktemp.3.
Thanks Justin and Chris for your input.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
