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]

Date:	Thu, 7 Feb 2013 09:18:32 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Pavel Shilovsky <piastry@...rsoft.ru>
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

On Thu, Feb 07, 2013 at 01:53:46PM +0400, Pavel Shilovsky wrote:
> 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.

But leave the newly-created file there--ugh.

> We can't grab it before atomic_open because we don't have an
> inode there.

If you can get the lock while still holding the directory i_mutex can't
you prevent anyone else from looking up the new file until you've gotten
the lock?

--b.

> 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.
--
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/