[Labeled-nfs] Client process label operation (OP_PUTCLIENTLABEL)

[Dave Quigley]

On Tue, 2007-12-18 at 02:24 +1100, James Morris wrote:
> On Mon, 17 Dec 2007, Dave Quigley wrote:
> 
> > Ok so this is how it works then. If the client wishes to use fscreate it
> > places it in the fattr4 structure sent over. If it is blank then the
> > process label is sent over, translated into the server's doi, and then
> > the server makes the decision on how to label. Why is this field needed
> > then? You can still get your functionality without it. I'm not saying
> > that I disagree with the functionality just that this item doesn't seem
> > necessary.
> 
> Ok, that should work.
> 
> > "Ok I think it is overly complicated to ask the client to enforce the
> > server's policy. That should be the job of the server. This is easily
> > handled since NFSv4 added an open operation. The only problem I see is
> > delegations and there seems to be only two reasonable ways to handle
> > this.
> 
> What about locally cached objects on clients?

Well the only local caching would be data. To get access to that data
the client is still going to need to make the open call which will do
the checking on both ends. This isn't an issue as long as there are no
delegations.

> 
> > Either we disable delegations, or it is a prerequisite that the
> > client and server must both be using the same policy." 
> 
> We can't break NFS by disabling features, and it seems extremely unlikely 
> that we can expect them to be using the same policy.
> 

We should probably move the specification document discussion to here
since we are repeating ourselves a bit.

"Its not breaking NFS. Delegations are handed out at the sole discretion
of the server. If the server is sees that labeled-nfs is being used it
is completely within its rights to disable delegations. The two policy
concept is something that fundamentally breaks the concept of
delegations to begin with." - Dave

> 
> - James