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