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