On Fri, Jan 07, 2011 at 01:32:27PM -0700, Theo de Raadt wrote: > So there is a mkdtemp(), but where is the AF_UNIX version?
Well it wouldn't be big thing to add but from a quick look it seems like nc would be the only user. > > I think it is important that people who do use mktemp(3) realize that > they must loop over failure (creating a new path each time), and they > need to use a "do not use the path from elsewhere unless the code that > opens it returns success" paradigm. mktemp(3) just provides a "potentially > unique name"; the expected gaurantees must be supplied by the caller. Maybe with something like this: +Where +.Fn mktemp +must be used, callers should ensure they detect failure when subsequently +attempting to create the file and generate a new name by calling +.Fn mktemp +again before retrying. Or maybe another example in the examples section. Index: mktemp.3 =================================================================== RCS file: /cvs/src/lib/libc/stdio/mktemp.3,v retrieving revision 1.45 diff -u -p -r1.45 mktemp.3 --- mktemp.3 27 Dec 2010 21:18:44 -0000 1.45 +++ mktemp.3 7 Jan 2011 21:15:11 -0000 @@ -72,12 +72,18 @@ does not actually create the temporary f opportunity during which another process can open the file instead. Because of this race condition, .Fn mktemp -should not be used in new code. +should not be used where +.Fn mkstemp +can be used instead. +Where +.Fn mktemp +must be used, callers should ensure they detect failure when subsequently +attempting to create the file and generate a new name by calling +.Fn mktemp +again before retrying. .Fn mktemp was marked as a legacy interface in -.St -p1003.1-2001 -and may be removed in a future release of -.Ox . +.St -p1003.1-2001 . .Pp The .Fn mkstemp
