> 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. :-) -- 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
