On May 1, 2014, at 10:16 AM, Tom Haynes <thomas.haynes@xxxxxxxxxxxxxxx> wrote: > > >> On May 1, 2014, at 7:07 AM, Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: >> >> On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes >> <thomas.haynes@xxxxxxxxxxxxxxx> 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. :-) > > And we’ve gone with #2. We can revisit the new attribute in NFSv4.3 if we find we actually have a use for it.-- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
