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

[J. Bruce Fields]

On Thu, Feb 07, 2019 at 01:33:11PM +0100, Volker Lendecke wrote:
> 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?

Linux currently has mandatory locking, sort of.  It's documented under
"Mandatory Locking" in that same fcnt man page, or there's more here:

	https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt

The existing interface isn't useful for Samba.  I think it would be easy
to design a new interface.  Implementing it might be hard, I don't know.
We'd need to avoid impact on people not using mandatory locks.  I'm more
worried about the fact that the existing implementation has the obvious
TOCTUO race.  We'd need to fix that first, and I'm not sure how.

Honestly I'd been hoping we could just deprecate mandatory locking
completely!  But if this is a priority then we should figure out how to
save it.

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

We should look at Pavel Shilovsky's patches.  He did define
O_DENYDELETE:

	https://lwn.net/Articles/557079/

> > > 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?
 
An NFS client can keep the delegation after it closes the file, I think
of it as independent of any one open.

The client can do more opens, and depending on the type of open may
perform them locally without informing the server.  (E.g. if it has a
read delegation then it can let an application open the file for read
without informing the server.)  When it's notified of a delgation
recall, it sends any existing opens to the server before returning the
delegation.

The underlying VFS interface which knfsd uses to implement delegations
does take a file description, and that works fine for us.

Does that answer your question?

> 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?

Sounds vaguely like NFS delegations.  But I don't know what a lease key
is, or what bumping an fd means.

--b.