On Wed, May 24, 2006 at 02:07:19AM +0200, Michael Kerrisk wrote: > 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 s/$/e/
> 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). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
