Hi Stef- > On Mar 15, 2018, at 6:07 AM, Stef Bon <stefbon@xxxxxxxxx> wrote: > > 2018-03-14 22:42 GMT+01:00 Eric W. Biederman <ebiederm@xxxxxxxxxxxx>: >>> >>> 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
