linux-kernel - Re: [RFC PATCH] locks: fix file locking on overlayfs

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: <20160719153602.GB3335@fieldses.org>
Date:	Tue, 19 Jul 2016 11:36:02 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Miklos Szeredi <mszeredi@...hat.com>
Cc:	Jeff Layton <jlayton@...chiereds.net>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-unionfs@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC PATCH] locks: fix file locking on overlayfs

On Tue, Jul 19, 2016 at 04:46:14PM +0200, Miklos Szeredi wrote:
> On Tue, Jul 19, 2016 at 4:01 PM, J. Bruce Fields <bfields@...ldses.org> wrote:
> > On Tue, Jul 19, 2016 at 02:27:44PM +0200, Miklos Szeredi wrote:
> >> This patch allows flock, posix locks, ofd locks and leases to work
> >> correctly on overlayfs.
> >>
> >> Instead of using the underlying inode for storing lock context use the
> >> overlay inode.  This allows locks to be persistent across copy-up.
> >
> > Remind me when the overlay inode is created--is it immediately on any
> > (even read-only) open?
> 
> So basically overlay has three types of inodes:  lower, upper (these
> are called underlying or real inodes) and overlay inode.
> 
> Overlay inode is created on lookup, just like any other filesystem.
> Overlayfs's own lookup then it proceeds to look up underlying dentry
> and stores ref in the overlay dentry.
> 
> Copy-up happens on read-write open (or other modifying operation),
> which creates inode on upper and copies data/metadata from lower inode
> to upper inode.

Thanks for the explanation. So, if I understand correctly:

Locking should look completely normal as long as all locking is done
through the overlay.

Locks may fail to conflict when expected if one of the overlayed layers
is accessed elsewhere somehow--but that's a reasonably easy rule to
document, and consistent with other overlayfs behavior.

--b.