Re: [nfsv4] Scribe 5/17

["Haynes, Tom" <[e-mail]>]

On Wed, May 23, 2012 at 02:35:16PM -0400, J. Bruce Fields wrote:
> 
> I assume you meant: "... only care about regular files that have open
> state", but I'm nost sure.
> 
> That wouldn't agree with what Dave's said.
> 
> Looking at http://tools.ietf.org/html/draft-ietf-nfsv4-labreqs-03 it
> says a couple different things:
> 
> 	Servers MUST provide a mechanism for notifying clients of
> 	attribute changes of files on the server."
> 
> I'd be willing to take "files" to mean regular files, except the
> sentence above says "Servers MUST be able to store and retrieve the
> security attribute of exported files as requested by the client", and in
> that case "files" was clearly meant to be all filesystem objects.
> 
> Then later for limited server mode it says "The server MUST inform
> clients when an object label changes for a file the client has open."
> 
> So I don't know.

BTW - Please bring this up on the Last Call for that document. :->

(see below for some comments)

> 
> My concern is just that the authors may not have overlooked the fact
> that in NFSv4 only regular files can be opened.  In which case we could
> end up with something that doesn't actually work for their purposes.
> 
> --b.
> 

I agree.

A goal of Labeled NFS is to remove the need for MAC based NFS servers to create
default labels for incoming NFS requests.

If we consider a case where the MAC NFS server running NFSv4.1 has an
implementation which simply maps client IP to a label:

192.168.34.21 -> Top Secret
192.168.23.10 -> Secret

then it is clear that the server has no means to inform the clients when
a security label on an object is modified.

So the only means the server has to interact via MAC policies is to
either accept or reject the operations as they try to access an object.

The minimum bar we have to meet is that above - it keeps parity with
existing implementations.

We can make improvements iff we know the client has state (open file handle,
directory delegation) that the server can reasonably detect. In such cases,
the server can notify the client of an attribute change on an object.

As for the Requirmens, what we want is probably:

       Servers SHOULD provide a mechanism for notifying clients of
       attribute changes of objects on the server.

       Servers MUST be able to store and retrieve the
       security attribute of objects as requested by the client.

-- 
[e-mail], ex-cfb