Justin,
> On Mon, May 22, 2006 at 02:20:55PM -0400, Christopher W. Curtis wrote:
> > Package: manpages-dev
> > Version: 2.02-2
> You should really update the package, as it changes pretty quickly.
> BTW, what suite are you running (stable sarge/testing etch/unstable
> sid) that has 2.02-2, or is this not a networked machine?
>
> > Quite simply, the man pages for tempnam.3 and mktemp.3 both say to use
> > mkstemp.3 but that man page says to never use the function and
> > recommends using tmpfile.3. tmpfile.3 seems happy to be called.
> I don't disagree that the situation is not ideal and should be fixed.
>
> > I hope that tmpfile() really is a secure call ... people seem confused.
> The low-level necessary thing is to use open() with flags
> O_CREAT|O_EXCL, which means "create a new file, but fail if it already
> exists". In a unix program, you can just loop around open() with
> various filenames (eg. from sprintf and a counter) to do this.
> glibc fopen() has the "x" flag which does this more portably.
>
> mkstemp.3
> This guarantees to open the file with O_EXCL (though it doesn't
> mention O_CREAT, and probably should),
Absolutely no reason to mention O_CREAT...
> so it is safe.
Yes, but not for the reason you cite.
> tempnam.3
> // TODO: malloc() ?
> This generates a filename which didn't exist at some point during the
> function call. It is possible to use it securely:
> char *t;
> FILE *fp;
> if (NULL==(t=tempnam(NULL, NULL)) ||
> NULL==(fp=fopen(t, "wx"))) {
> fputs("Failed to create temporary file\n", stderr);
> exit(EXIT_FAILURE);
> }
>
> But if you don't use the "exclusive" mode, then it is insecure. gcc
> warns about use of this function.
Not really; the real problem is the
use of environment variables. TMPDIR could be used to influence
a program to create a file in the "wrong" place. Glibc's
tempnam() ignores TMPDIR if the program is set-user-ID, but there
is no guarantee for other implementations.
> mkdtemp.3
> "Introduced in OpenBSD"; 'nuff said. (Just kidding). Since it
> creates the directory (and presumably fails or retries if it exists),
> it is safe to use; since it modifies a string it is passed instead of
> a static buffer, it is even thread safe.
>
> 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.
> mktemp.3
> This is another classically-buggy function. And again, there's not so
> much something wrong with the function, but with how people use it.
Wrong. The problem is much the same as tmpnam().
You are stating your partial, and wrong understanding of things
as being authoritative. This is not useful.
> Michael has mentioned the Debian-specific change; I'm including the
> relevant diffs for review.
>
> Suggestions to improve these pages would be welcomed.
I have already suggested the main point that needs improvement.
> --- manpages-2.28.orig/man3/mkstemp.3
> +++ manpages-2.28/man3/mkstemp.3
> @@ -75,12 +75,16 @@
> .BR mkstemp ().
> .SH "CONFORMING TO"
> 4.3BSD, POSIX 1003.1-2001
> -.SH NOTE
> +.SH NOTES
> The prototype is in
> .I <unistd.h>
> for libc4, libc5, glibc1; glibc2 follows the Single Unix Specification
> and has the prototype in
> .IR <stdlib.h> .
> +
> +Don't use this function, use
> +.BR tmpfile (3)
> +instead. It is better defined and more portable.
Remove this patch.
> .SH "SEE ALSO"
> .BR mkdtemp (3),
> .BR mktemp (3),
> --- manpages-2.28.orig/man3/tmpfile.3
> +++ manpages-2.28/man3/tmpfile.3
> @@ -36,8 +36,8 @@
> .B FILE *tmpfile (void);
> .fi
> .SH DESCRIPTION
> -The \fBtmpfile\fP() function generates a unique temporary filename.
> -The temporary file is then opened in binary read/write (w+b) mode.
> +The \fBtmpfile\fP() function opens a unique temporary file in binary
> +read/write (w+b) mode.
This change has already (2.31) made its way upstream.
> The file will be automatically deleted when it is closed or the
> program terminates normally.
> .SH "RETURN VALUE"
> --- manpages-2.28.orig/man3/tmpnam.3
> +++ manpages-2.28/man3/tmpnam.3
> @@ -99,7 +99,7 @@
> .IR "<stdio.h>" .
> .SH BUGS
> Never use this function. Use
> -.BR mkstemp (3)
> +.BR tmpfile (3)
No. This is not needed. mkstemp() is the right alternative.
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]
