[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] tempfile creation
From: |
Chad Walstrom |
Subject: |
Re: [Nmh-workers] tempfile creation |
Date: |
Wed, 27 Apr 2005 14:33:18 -0500 |
User-agent: |
Mutt/1.5.6+20040907i |
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 <address@hidden> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
signature.asc
Description: Digital signature
- Re: [Nmh-workers] tempfile creation, (continued)
- Re: [Nmh-workers] tempfile creation, Mike O'Dell, 2005/04/27
- Re: [Nmh-workers] tempfile creation, Mike O'Dell, 2005/04/27
- Re: [Nmh-workers] tempfile creation, Neil W Rickert, 2005/04/27
- Modernizing core code (was Re: [Nmh-workers] tempfile creation, heymanj, 2005/04/27
- Re: Modernizing core code (was Re: [Nmh-workers] tempfile creation, Ralph Corderoy, 2005/04/28
Re: [Nmh-workers] tempfile creation,
Chad Walstrom <=
- Re: [Nmh-workers] tempfile creation, Josh Bressers, 2005/04/27
- Re: [Nmh-workers] tempfile creation, Mike O'Dell, 2005/04/27
- [Nmh-workers] [OT] nit (was Re: tempfile creation), Chad Walstrom, 2005/04/27
- Re: [Nmh-workers] tempfile creation, Ralph Corderoy, 2005/04/28
- Re: [Nmh-workers] tempfile creation, Mike O'Dell, 2005/04/28