Re: mkstemp

[Reuben Thomas]

On 27 April 2011 03:24, Bruno Haible <address@hidden> wrote:
>> Does setting a 0600 umask (as glibc does) sound like a good thing to
>> add to the mkstemp-safer functions?
>
> The application can call chmod() on its own. Why push this
> into mkstemp-safer?

I'm not suggesting chmod (that would surely create a race condition?),
I'm suggesting creating the file with known permissions, as glibc already
does. From mkstemp(3):

       The file is created with permissions 0600, that is, read plus
write for owner only.  (In glibc
       versions 2.06 and earlier, the file is created with permissions
0666, that is, read and write
       for all users.)  The returned file descriptor provides both
read and write access to the file.
       The file is opened with the open(2) O_EXCL flag, guaranteeing
that the caller is the process
       that creates the file.

I am simply proposing to allow non-GNU systems to benefit from an easy
and valuable security fix that is already in production in GNU.

> Programmers who use mkstemp / mkstemps / etc. also need to care about
> cleanup in case of Ctrl-C or SIGHUP, otherwise /tmp fills up. (Cf. module
> 'clean-temp'.) How do you want to deal with this extra requirement?

clean-temp already seems to deal with this, from what you're saying, but I don't
think it is useful in my case, which is to use a temporary file while saving a
Zile buffer. After writing it is renamed over the original file.
Hence, the temporary
file has to be on the same volume as the destination, and for simplicity it's in
the same directory. Since it's data that the user wants to save, there's no
attempt made to remove it should Zile be interrupted before the rename
completes.

However, this suggests that the gnulib documentation for mkstemp
should direct the programmer to clean-temp, something like:

"If you are creating temporary files which will later be removed, consider
using the clean-temp module, which avoids several pitfalls of using mkstemp
directly."

-- 
http://rrt.sc3d.org