Re: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL

[Tom Haynes <thomas.haynes@primarydata.com>]

> On May 1, 2014, at 7:07 AM, Jeff Layton <jlayton@poochiereds.net> wrote:
> 
> On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes
> <thomas.haynes@primarydata.com> wrote:
>> In my issues file, I have:
>> 
>> 4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to
>>   be?  Is seLinux going to support it?
>> 
>>   The Labeled NFS prototype in use does not currently support
>>   change_sec_label.
>> 
>>   In the past, we argued about how big it needed to be - we need
>>   to close down on this.
>> 
>> If we look at the current text in the NFSv4.2 draft, we see:
>> 
>>      The second change is to provide methods for the client to
>>      determine if the security label has changed. A client which
>>      needs to know if a label is going to change SHOULD request a
>>      delegation on that file. In order to change the security
>>      label, the server will have to recall all delegations. This
>>      will inform the client of the change. If a client wants to
>>      detect if the label has changed, it MAY use VERIFY and NVERIFY
>>      on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL
>>      has been modified.
>> 
>> So the first question is do we need two methods for detecting that the label
>> has changed?
>> 
>> Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt
>> covers
>> how the client could use delegations to detect a label change.
>> 
>> To quote Trond out of context:
>> 
>> but that is the only option I can see for implementing a cache
>> consistency model for labels. Without it, the choices are:
>> 
>> 1) always fetch the label as part of every COMPOUND.
>> 2) assume the label never changes on the server.
>> 
>> The main use cases that have been presented for Labeled NFS on Linux
>> would tend to push me towards door number 2, Monty please...
> 
> In principle, the label should only rarely change, but they do change
> for various reasons (admin goofs and forgets to set the label in the
> first place and then needs to fix it, SELinux policy changes mandate
> that a label changes from some type to another, etc). I think assuming
> that the label never changes would be very problematic. If the label
> does change, you'd basically need to remount on the client.
> 
> That said, I don't see any real need to treat the label differently
> from any other attribute. If you're trying to use these for
> client-side enforcement, then you just need to be aware that you can
> race with label changes on the server.
> 
>> 
>> So a client could assume that the label never changes the majority
>> of the time. Once it decides it does need to start checking for a change
>> in the label, it can get a delegation.
>> 
>> If we do need the attribute, what size does it need to be?
>> 
>> There has been mention of it being a hash or a timestamp.
> 
> I guess part of the problem is that we're trying to do client-side
> enforcement with these labels, and that's always going to be
> difficult. The server should really be what's doing the enforcement.
> Once we have that, we can just treat the security label like any other
> attribute and not worry about cache coherency.

So are you advocating one of:

1) No detection of change
2) Client gets a delegation
3) Use the new attribute

FWIW, I like #2. :-)