Re: mktemp's access mode and inotify

[Eric Blake]

On 05/12/2011 12:05 PM, David Thomas wrote:
> So I've come across something I think is interesting, and may turn
> into an associated bug report / feature request / patch, but I am
> wondering first just generally what people's thoughts are.

Thanks for the report.

> 
> It specifically has to do with how mktemp plays with inotify.  Since
> mkstemp opens the file with the write bit set (or, well, technically
> unset - but "able to read") when the file is closed inotify receives a
> IN_CLOSE_WRITE event on the directory.

mktemp doesn't play with inotify any differently than any other app that
calls open(,O_CREAT|O_EXCL|O_RDWR).

> to play well, ensuring that a process listening for IN_CLOSE_WRITE
> only sees a file once it is complete (absent error, which must be
> handled correctly - but we're avoiding any chance of catching the file
> incomplete-but-still-to-be-completed, as well as a spurious wakeup of
> the listening process).

Oh, so you're basically asking whether instead of using mkstemp(3)'s
POSIX-mandated O_RDWR, mktemp(1) should use O_RDONLY when creating the
temporary file?  The problem is that even though mktemp(1) uses a
modified version of glibc's __gen_tempname under the hood for creating
the file (as exposed by gnulib and slightly modified by coreutils), the
glibc interface explicitly masks off O_ACCMODE and replaces it with
O_RDWR, so there is no library interface for requesting an O_RDONLY
creation of a temporary file that will just then be closed.

Maybe it makes to make yet another tweak to
coreutils/gl/lib/tempname.c.diff to let coreutils also specify the
preferred access mode to use then generating a temp name where it will
just be closed afterwards, for use in mktemp(1).

Inotify is not part of POSIX, so there is no way a POSIX compliant
application can tell whether mktemp(1) used O_RDONLY or O_RDWR, so I
don't see how this can affect anything other than fewer unwanted inotify
events; I guess it seems safe enough.  Would you like to contribute a patch?

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature