Re: split stdio-safer into fopen-safer, tmpfile-safer

[Paul Eggert]

Ben Pfaff <address@hidden> writes:

> I was worried that there was something bigger here.  Usually a
> "safety" issue is something more important than leaving a
> temporary file undeleted or limiting their number, like the
> possibility of a security hole, a segfault, etc.

Eric Blake mentioned some of the problems, but to my mind the biggest
problem with tmpfile is that implementations typically unlink the file
immediately after creating it, which means that a long-running process
that uses tmpfile can exhaust /tmp even though "ls -l /tmp" doesn't
see anything amiss.  This can be a real denial-of-service problem
(usually inadvertent).  A superuser can figure it out with lsof or the
equivalent, but ordinary users can easily be flummoxed.

There are a few segfaultish problems which people don't often run
into.  I just now scanned the glibc code and discovered that it
mishandles the case of setting TMPDIR to a string that is 4 GiB long
"/tmp/./././././...." on a 64-bit host.  (If you have the energy
perhaps you can get this bug fixed in glibc.)  But this sort of
problem often occurs in the "safer" temporary-file primitives as well.