Hi Stef-

On Mar 15, 2018, at 6:07 AM, Stef Bon [off-list ref] wrote:

2018-03-14 22:42 GMT+01:00 Eric W. Biederman [off-list ref]:

quoted

quoted

Please tell me if I'm hijacking the thread.

Unless something brings us to non-consensus about the patches to merge
we are good.  I think this is an area that need some discussion.

The big big thing right now, as I understand it, is these mechanisms that
nfs uses to keep the cache in sync are not clearly reflected in the vfs
in a way that ima can take advantage of them.

Chuck you mean fschange notifications methods like
NT_TRANSACT_NOTIFY_CHANGE for cifs.

No, I don't mean notification. That's a different mechanism entirely.

NFSv4 delegations are similar to SMB oplocks. It's a protocol
guarantee that the server will tell the client that holds a delegation
when another client wants conflicting access to a file. The client
then has an opportunity to update the file with anything it has cached
and then the client releases the delegation. Servers have the option
of granting a delegation for a file when it is OPENed.

NFSv4 OPEN with share deny is similar to the way that SMB does OPENs.
When a user OPENs a file this way, no other user or client is allowed
to access it until the user CLOSEs the file.

I believe that NFS4 has something simular.
These mechanism will inform the client when a file in a watched
directory is changed.
This is not yet supported in Linux (these methods are not triggered
any way when setting a watch using inotify for exmple).
There was support with dnotify
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/cifs/cifssmb.c#n6393).

But these methods are triggered by the user and not the VFS/kernel and
therefore cannot garantee that all files on the client
are the same as on the server.
This also counts for a read delegation with nfs and methods like
leases in a client server environment.

Stef

--
Chuck Lever