[darcs-devel] Temporary files issue

David Roundy droundy at darcs.net
Wed Feb 7 11:27:30 PST 2007


On Wed, Feb 07, 2007 at 02:12:03PM -0500, Zachary P. Landau wrote:
> On Wed, Feb 07, 2007 at 07:20:13PM +0100, Juliusz Chroboczek wrote:
> > >> I think most /tmp dirs have the t-flag set, which means you must
> > >> be the owner of a file to delete it from the directory. In those
> > >> cases it seems safe, but I don't know for certain.
> > 
> > I'd formulate it in a different manner.  Using /tmp is most certainly
> > safe on sane Linux and BSD systems.  It's anyone guess what happens on
> > other OSes.
> > 
> > In other words -- unless there's someone here who fully understands
> > the semantics of the sticky bit on Solaris and HP/UX, it's not a can
> > of worms we want to open.
> 
> I wonder if instead we should be using tmpfile().  The Linux manpage for
> it says that it conforms to POSIX.1-2001, so I would hope the other OSes
> will implement it correctly.  The other benefit is that tmpfile() will
> determine the directory to use.  If some OS for some reason doesn't have
> a secure /tmp, then it might provide another directory for tmpfile to
> use.

tmpfile() would be nice, but the file is deleted automatically when the
handle is closed (perhaps deleted before the handle is returned?), so we
can't use it when we want a filename that we can pass to emacs.

> I guess my main issue is that if calls like mkstemp() and tmpfile() are
> meant for securely creating temporary files and an OS does not implement
> it correctly, darcs will only be one of the many applications that will
> be susceptible to attack.  The issue at that point would be the security
> of the OS, not of an application.  Sure a workaround for applications
> could be made, but that feels like a hack around a bigger problem.

My concern is just that my understanding of how to properly use mkstemp()
and tmpfile() is that you can't close the file or rely on its name, both of
which we need to do in order to interface with external programs.

> I don't mean to sound like I'm set on using /tmp (or tmpfile()).  But it
> would provide a clean solution to the temp file problem, so I don't want
> to disregard it unless there really is a valid reason to avoid it.

A clean solution would certainly be nice... I just don't see a solution,
unless it's just that "once you've created a file in /tmp, you can do
whatever you like with it, as long as you don't delete it, and you're still
safe from attack".  If that sentence were true, we'd be fine using /tmp
with mkstemp() using the $TMPDIR (or just /tmp)---I still don't see how we
could use tmpfile().
-- 
David Roundy
Department of Physics
Oregon State University
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070207/5089a6c0/attachment.pgp


More information about the darcs-devel mailing list