[PATCH] flock() files even with a permissive share mode.

[Volker Lendecke]

On Wed, Feb 06, 2019 at 04:15:06PM -0500, J. Bruce Fields wrote:
> On Wed, Feb 06, 2019 at 09:26:09PM +0100, Volker Lendecke wrote:
> > On Wed, Feb 06, 2019 at 03:13:28PM -0500, J. Bruce Fields via samba-technical wrote:
> > > I could help write up or compile some sort of "introduction to NFS
> > > locking for SMB developers".  NFSv4 has byte-range locks, share locks,
> > > and delegations, you're interested in all three?
> > 
> > Very much so. For a start:
> > 
> > brlocks == brlocks (how similar are they to Posix in NFS?)
> 
> Right.  They're the same as posix locks, so the documentation under
> "Advisory record locking" in the fcntl(2) man page should all apply.
> They're fully implemented and commonly used on both the client and
> server side.

An interop question here would be how to guarantee the mandatory
nature of the locks coming in via SMB. We already have code to pass on
locks to the kernel via fcntl, and we have code to check what the
kernel set externally on read and write. But would it possible to
extend the guarantee that nobody writes a locked area, even from the
other protocols?

> > Share locks == share modes (i.e. per-open locks in different modes)
> 
> I think this short section has what you need:
> 
> 	https://tools.ietf.org/html/rfc7530#section-9.9
> 
> The Linux client does not use them, and knfsd implements them itself
> without involving the vfs--which means they're enforced between nfs
> clients, but have no effect on non-NFS users of the same filesystem
> (including Samba).  I doubt they're used much.

Here things start to get interesting. How can we interact with the
kernel regarding this? Share modes are used in SMB all the time, and
they are important to get right.

One difficulty beyond READ and WRITE is the SMB way of deleting files:
First "open for delete", then set a "delete on close flag" and then
close. We must deny the open if someone else has O_DENYDELETE set.

> > delegations == oplocks/leases (i.e. permission to cache contents)
> 
> Yes.  This is a little more complicated.  This:
> 
> 	https://tools.ietf.org/html/rfc7530#section-1.4.6
> 
> might be a good starting point.
> 
> A client may hold a read delegation or a write delegation on a file.

Is this really on a file or is it on an open handle? What I read from
the rfc this sounds like per-fd, which would be oplocks. SMB2 has
extended this significantly to per-inode/per-client leases. One client
can have multiple file descriptors open with the same lease key. One
lease break affects all fd's, and a subsequent open acquiring fresh
caching permissions also bumps up all fd's with the same lease key.
Does NFS have an equivalent there?

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-370000-0, mailto:kontakt at sernet.de
Gesch.F.: Dr. Johannes Loxen und Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de