nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] tempfile creation

2005-04-27 12:37:07
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 */

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
<Prev in Thread] Current Thread [Next in Thread>