Subject: Re: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL

From: Jeff Layton <[email-masked]>
Date: Thu, 1 May 2014 10:07:06 -0400

On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes
<[email-masked]> 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.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 1 May 2014 07:16:24 -0700

> On May 1, 2014, at 7:07 AM, Jeff Layton <[email-masked]> wrote:
> 

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

---

From: Tom Haynes <[email-masked]>
Date: Fri, 2 May 2014 11:31:48 -0400

> 2) Client gets a delegation

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.