[Top][All Lists]

[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

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 */

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]