[Labeled-nfs] [PATCH 13/13] NFSD: Label change notification for NFSv4 Server

[Matthew N. Dodd]

Trond Myklebust wrote:
> On Tue, 2007-11-20 at 09:48 +1100, James Morris wrote:
>> A possible approach for dealing with all of these is to use a 
>> per-procedure OP which is prefixed in a similar manner to SEQUENCE, when 
>> security labeling is active.  It may be possible to optimize this at the 
>> server so that an updated file security label (or ineed the entire 
>> security OP) is only sent if required.
> 
> Right. You could use a stateid to represent the 'state of the current
> security label', and define an OP to tag all subsequent OPs in the
> COMPOUND (like PUTFH 'tags' all future OPs with a current filehandle).
> 
> That model gives the server a callback-free method for rejecting an
> operation if ever it sees that your idea of the file security labelling
> differs from its internal state.
> 
> You could even stack labels in the same way that SAVEFH and RESTOREFH
> do, so that operations like LINK and RENAME which take more than one
> filehandle can work.

Ok, so I implemented "OP_PUTFILELABEL" and shipped the client's idea of 
the current file label with the "write" operation, just to see how well 
this would work.

The server can error out if the labels differ but the client keeps 
buffering output for the file and retrying.  I'm not seeing how RPC 
return status makes its way up to the write code.  (Or to the userland 
for that matter.)

Clearly logic must be added at some point in the call chain to handle 
"stale label" errors, and refetch the label.  This won't help as user 
data has already been added to the filesystem buffer cache.

Anyhow, I'll carve out the patches and post them if anyone cares to verify.

The callback stuff implemented earlier does work.  I'm still not seeing 
what the original objection to it is and how the above mess is any better.