Subject: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL

From: Thomas Haynes <[email-masked]>
Date: Sat, 26 Apr 2014 09:35:22 -0700

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

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.

---

From: Thomas Haynes <[email-masked]>
Date: Sat, 26 Apr 2014 09:37:25 -0700