linux-kernel - Re: [PATCH v2 3/8] vfs: Add O_DENYREAD/WRITE flags support for open syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKywueS6oGNu9r_bypu32A89pOoiGb47kjXqw2ZcZQhZK+JV3g@mail.gmail.com>
Date:	Thu, 7 Feb 2013 13:53:46 +0400
From:	Pavel Shilovsky <piastry@...rsoft.ru>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
	wine-devel@...ehq.org
Subject: Re: [PATCH v2 3/8] vfs: Add O_DENYREAD/WRITE flags support for open syscall

2013/2/5 J. Bruce Fields <bfields@...ldses.org>:
> On Tue, Feb 05, 2013 at 03:45:31PM +0400, Pavel Shilovsky wrote:
>> 2013/1/31 J. Bruce Fields <bfields@...ldses.org>:
>> > On Thu, Jan 17, 2013 at 08:52:59PM +0400, Pavel Shilovsky wrote:
>> >> If O_DENYMAND flag is specified, O_DENYREAD/WRITE/MAND flags are
>> >> translated to flock's flags:
>> >>
>> >> !O_DENYREAD  -> LOCK_READ
>> >> !O_DENYWRITE -> LOCK_WRITE
>> >> O_DENYMAND   -> LOCK_MAND
>> >>
>> >> and set through flock_lock_file on a file.
>> >>
>> >> This change only affects opens that use O_DENYMAND flag - all other
>> >> native Linux opens don't care about these flags. It allow us to
>> >> enable this feature for applications that need it (e.g. NFS and
>> >> Samba servers that export the same directory for Windows clients,
>> >> or Wine applications that access the same files simultaneously).
>> >
>> > The use of an is_conflict callback seems unnecessarily convoluted.
>> >
>> > If we need two different behaviors, let's just use another flag (or an
>> > extra boolean argument if we need to, or something).
>>
>> Ok, we can pass "bool is_mand" to flock_lock_file that will pass it
>> further to flock_locks_conflict.
>>
>> >
>> > The only caller for this new deny_lock_file is in the nfs code--I'm a
>> > little unclear why that is.
>>
>> deny_lock_file is called not only in the nfs code but also in 2 places
>> of fs/namei.c -- that enable this logic for VFS.
>
> Oops, apologies, I overlooked those somehow.
>
> What prevents somebody else from grabbing a lock on a newly-created file
> before we grab our own lock?
>
> I couldn't tell on a quick look whether we hold some lock that prevents
> that.

Nothing prevents it. If somebody grabbed a share mode lock on a file
before we call deny_lock_file, we simply close this file and return
-ETXTBSY. We can't grab it before atomic_open because we don't have an
inode there. Anyway, we can't make it atomic for VFS without big code
changes, but for CIFS and NFS it is already atomic with the discussed
patch.

-- 
Best regards,
Pavel Shilovsky.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/