coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mktemp's access mode and inotify


From: Eric Blake
Subject: Re: mktemp's access mode and inotify
Date: Thu, 12 May 2011 13:31:55 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10

On 05/12/2011 12:54 PM, David Thomas wrote:
>> 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?
> 
> A very good point.  I guess my only concern would be whether a POSIX
> compliant libary/OS could require write access to create a file

open(file,O_RDONLY|O_CREAT|O_EXCL,0600) creates a read-write file, even
though the fd only uses the read permissions on that file.  There's
nothing in POSIX that requires O_CREAT to be paired with O_RDWR or
O_WRONLY.  The inotify event that you are worried about is the
CLOSE_WRITE when an O_RDWR file is closed, where if we use O_RDONLY,
we've avoided the inotify event.

For that matter, POSIX requires that
open(file,O_RDWR|O_CREAT|O_EXCL,0000) creates a file where the fd has
more permissions than the mode bits of the resulting file - no one else
can open the file name with read or write permissions (without a chmod
first, of course), but anyone owning a copy of the original fd can read
and write to their heart's content.  In fact, you can even set umask()
to 0777 (forcing all files to have mode 000 on creation, regardless of
the third argument to open()), although that's seldom done in practice :)

The thing to remember is that _during creation_, the O_ACCMODE bits of
the fd are orthogonal to the mode bits assigned to the inode; there's
nothing wrong with creating an inode with more or less permissions than
the fd used to first access it.  It's only when opening an existing file
where you start to get interplay where O_ACCMODE can't grant more rights
than what the existing mode bits (and ACLs and SELinux labels) on the
inode permit, but you can still open the fd with less rights than what
the mode bits allow.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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