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 <chewie(_at_)wookimus(_dot_)net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */
signature.asc
Description: Digital signature
_______________________________________________ Nmh-workers mailing list Nmh-workers(_at_)nongnu(_dot_)org http://lists.nongnu.org/mailman/listinfo/nmh-workers
| Previous by Date: | Re: [Nmh-workers] sorting on X-Spam headers, Jerry Peek |
|---|---|
| Next by Date: | Re: [Nmh-workers] tempfile creation, Josh Bressers |
| Previous by Thread: | Re: Modernizing core code (was Re: [Nmh-workers] tempfile creation, Ralph Corderoy |
| Next by Thread: | Re: [Nmh-workers] tempfile creation, Josh Bressers |
| Indexes: | [Date] [Thread] [Top] [All Lists] |