On Wed, Apr 27, 2005 at 11:01:45AM -0400, Mike O'Dell wrote: > if i were to hazzard a guess, the reason the code doesn't use > mkstemp() is that [1] the code cited is likely well more than twice > age of mkstemp() [2]and nobody has gone looking for things to fix > that were still (apparently) working. (big grin)
In sbr/m_scratch.c, it looks like there's a comment made by "Doug" with respect to postponing the mkstemp(3) work until "later". Additionally, looking at the manpage for mkstemp(3) on a GNU/Linux system reports this note:: "Don't use this function, use tmpfile(3) instead. It is better defined and more portable." Neither tmpfile(3) nor mkstemp(3) give a file name as a return value, rather a file stream or file descriptor, respectively. This breaks the use of a temp file as a staging area for a potentially permanent file (ala rename(2) or link(2)) and would require a more extensive rewrite of the nmh utilities. Alternatively, m_scratch.c could be patched to look at TMPDIR or P_tmpdir defined in stdio.h to construct the template path. Curious as to how tmpfile(3) works, I created a simple "Hello, World" application with glibc and gcc and ran strace on it. Here's what I got: open("/tmp/tmpfr0QcUf", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 unlink("/tmp/tmpfr0QcUf") = 0 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) brk(0) = 0x804a000 brk(0x806b000) = 0x806b000 brk(0) = 0x806b000 fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 Pretty cool. Opens with read/write, truncates the file, gets an exclusive lock, and with owner-only permissions. Then it UNLINKS the file. ;-) Tricky. Short of running ``dd`` on the block device the filesystem lives on, you're not likely to find the file or its contents. If you have this level of access, security isn't a barrier for you anyway. Additionally, using tmpfile and does break the ability to manually recover files the utilities are constructing in the event of a coredump. How important that might be, I don't know. > the question about /tmp is probably related the security issues and > how difficult it has been to make /tmp files robust against > hijacking. Probably, though making the location of temp files configurable might be a good idea. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */
signature.asc
Description: Digital signature
_______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers