[PATCH v3 4/4] fuse: define the filesystem as untrusted
chuck.lever at oracle.com
Thu Mar 15 13:53:10 UTC 2018
> On Mar 15, 2018, at 6:07 AM, Stef Bon <stefbon at gmail.com> wrote:
> 2018-03-14 22:42 GMT+01:00 Eric W. Biederman <ebiederm at xmission.com>:
>>> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive