Subject: Re: [nfsv4] [LNFS] Meeting Notes for 04/29/11

From: Jarrett Lu <[email-masked]>
Date: Tue, 03 May 2011 13:36:33 -0700

On Fri, Apr 29, 2011 at 3:07 PM, Thomas Haynes<[email-masked]>  wrote:

> >  + Object label changes
> >  A very good discussion, I'll try to capture the key points.
> >  Nico pointed out that if a DAC is changed on a file after it has
> >  been opened, then POSIX semantics state that it retains the
> >  rights it had established in the open.
> >  What then did we want to have occur with a MAC label change?
> >  a) Instantaneous? Different than DAC.
> >  b) Delayed? I.e., do we want to allow the client to flush buffers?
> >  But then how does the app get notified?
> >  We also talked about the implication of having an outstanding
> >  delegation.
> >  Tom brought up that if the server has exports, then it may already
> >  handle these situations when a client is suddenly denied access
> >  to the filesystem.
> >  Jarrett asked what happens with local filesystems when a MAC label changes?
> >  He took an AI to investigate what the Trusted Solaris extensions do.

I looked into local file object relabeling behavior on Solaris trusted 
extensions.
The files must be tranquil before they can be relabeled. This behavior 
is not
what I had expected. But it is part of the MAC model Solaris implemented.

> >  In the end, we decided that the revocation was to occur instantaneously.

I believe immediate revocation is correct behavior for LNFS. Allowing
a process to continue writing to a file whose label has been changed
is a MAC violation.

- Jarrett

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 3 May 2011 15:47:22 -0500

On May 3, 2011, at 3:36 PM, Jarrett Lu wrote:

> 
> 
> I looked into local file object relabeling behavior on Solaris trusted extensions.
> The files must be tranquil before they can be relabeled. This behavior is not

Thanks for this info.

I think that a server which supports Trusted Solaris extensions can enforce
this by either disallowing the attribute change if the file is open by any
client or by forcing all clients to first close the file.

While I think this is an implementation issue, we do need to consider what
happens if the server rejects the attribute change. I think that we should
consider this to be an error and decide if we need to use a new error code.

BTW - SETATTR's IMPLEMENTATION section has this to say:

   If the object whose attributes are being changed has a file
   delegation that is held by a client other than the one doing the
   SETATTR, the delegation(s) must be recalled, and the operation cannot
   proceed to actually change an attribute until each such delegation is
   returned or revoked.  In all cases in which delegations are recalled,
   the server is likely to return one or more NFS4ERR_DELAY errors while
   the delegation(s) remains outstanding, although it might not do that
   if the delegations are returned quickly.

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 May 2011 15:52:47 -0500

> consider this to be an error and decide if we need to use a new error code.

Yes, we do.

>   if the delegations are returned quickly.

Delegation return != no open file references.

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 3 May 2011 15:55:10 -0500

> Delegation return != no open file references.

Correct, but one of the remaining agenda items was what
we need to do with delegations.

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 May 2011 16:02:38 -0500

> we need to do with delegations.

Yeah, but now we're talking about what to do when the label changes
given what Solaris TX does, and Solaris TX disallows the label change
while there are open file references (though obviously it can't know
in the case of a file shared with NFS < v4.1).  So we're past "what to
do about delegations" and into "what can we do about outstanding open
file references?"  My understanding is that 4.1 allows the server to
require stateful-ness, so that might be an option.

OTOH, I wouldn't object to immediate revocation -- I just want to give
proper consideration to the Solaris TX approach.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Tue, 03 May 2011 16:10:46 -0700

On 05/ 3/11 02:02 PM, Nico Williams wrote:
> On Tue, May 3, 2011 at 3:55 PM, Thomas Haynes<[email-masked]>  wrote:
> in the case of a file shared with NFS<  v4.1).  So we're past "what to

I think NFS server should immediately revoke delegations and make
all file handles stale before relabeling a file.

- Jarrett

> Nico
> --
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 3 May 2011 18:40:10 -0500

> all file handles stale before relabeling a file.

The 5661 spec is pretty clear about what has to happen with
delegations, they should be recalled.

But for the other case, where a client has a file open, but
without a delegation, we should not stale the filehandle.

The label change may not be more restrictive for the client.

As an example, consider a file that is Unclassified and
which is being edited by a process with Top Secret. Someone
changes the label to Secret. Why should we force that
process to lose access?

We might also be able to envision non-hierachical models
where the smart client might be able to make decisions
based on the attribute change.

I think that both the delegation case and the example of
Solaris TX waiting for a tranquil file show that a client
has to be prepared for a server to return an error when
it tries to change a security label.

Consider what happens when a delegation is outstanding.
The server might:

1) Wait as it recalls all delegations
2) return NFS4ERR_DELAY to indicate that delegations are being recalled

I think the model we should adopt is that either delegations
or DOI implementations may cause a security label change
to be delayed until some resources are freed. Once those
resources are freed, then the server will allow the
label change to take place.

The effects are instant - if the new label causes a subject
to lose write access, then all writes still on the client are
rejected. Note that I say subject, any given client might
have multiple processes accessing the file. One might
lose access during a label change, but another might
not. We should not force the second to pay the price
for the first.

---

From: Jarrett Lu <[email-masked]>
Date: Tue, 03 May 2011 17:01:41 -0700

> changes the label to Secret. Why should we force that

In MLS MAC world, to be able to write to an object, the
subject label and object label must match. A higher labeled
subject can read a lower labeled object, but can't write it.

> 2) return NFS4ERR_DELAY to indicate that delegations are being recalled

Can this delay be indefinite?

> not. We should not force the second to pay the price

I try to get the semantics correct; you try to optimize. ;-)
I'm not against optimization as long as the semantics and
behavior remain correct.

- Jarrett

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 3 May 2011 20:46:25 -0500

> subject can read a lower labeled object, but can't write it.

I stand corrected. And I actually appreciate these insights.

My point still is that we might have cases where revoking the rights
is not the correct action.

> Can this delay be indefinite?

This is another good question.

In the case of recalling delegations, no, it must follow the
model in 5661 where the server first recalls and then if
the client is not responsive, it revokes the delegation.

As for the DOI implementation, I believe that is an implementation
issue and out of the control of our spec. I.e., if Solaris TX
states that a file must not be opened by another client when
the label is changed, then such a DOI has the right to
wait until the preconditions are met.

This might be a reason to differentiate between NFS4ERR_DELAY
with something like NFS4ERR_DOI_BLOCKING.

> I'm not against optimization as long as the semantics and

I was thinking about this, I think I saw the terminology
of "Stale the filehandle" versus the change we talked about
in the meeting. I believe we have the same intent here.

I think we can state the semantics as:

When the label changes, the new value applies immediately.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 03 May 2011 23:05:07 -0700

> is not the correct action.

You may be right. I still think we should go with the simpler model.
Relabel is very rare. The additional complexity in design and
implementation probably doesn't pay off in this case.

> with something like NFS4ERR_DOI_BLOCKING.
The "tranquility" example I gave earlier refers to usage of local
file systems. I think administrator can force the system into
a tranquil state (e.g. by killing all open processes if needed).
In NFS case, it probably suffices to just revoke all leases and
make all handles stale.

> When the label changes, the new value applies immediately.

In agreement.

Thanks.

- Jarrett