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

From: Thomas Haynes <[email-masked]>
Date: Fri, 29 Apr 2011 15:07:37 -0500

Attendees
--------------

Tom Haynes (NetApp)
Dave Quigley (davequigley.com)
Jarrett Lu (Oracle)
Peter Staubach (EMC)
David Black (EMC)
Nico Williams (cryptonector.com)

Agenda
-----------

+ IETF Note Well Agreement

+ Use Cases

We have wrapped these up.

+ RPCSEC_GSSv3

Nico has delivered some writeup on client and server implementation
expectations. He will incorporate them into the draft based on group
feedback, most notably David Black.

+ Capabilities

10,000 ft overview: A secure and opaque cookie that the server can
send to the client. When the server gets the cookie back, it can look in
the cache to see if it is authenticated. If not in the cache, can use the
cryptographic properties to authenticate and refill the cache.

We decided not to further explore capabilities for LNFS.

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

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

We then had a very heated discussion about what was a dumb server.
It turned out there were two camps:

1) A server which did not speak LNFS, i.e., what we have today.

2) A server which could accept and return labels, but which could
not act on those labels in any form.

We decided that they both are correct in that we want to consider the
following scale of servers:

A) Non-LNFS aware
B) LNFS passing
C) Smart

The intersection of this discussion with Object Label changes is that if
you have smart clients and LNFS passing servers, then there is no
way for the server to revoke access when a label changes. Instead,
it needs to send notification to the smart clients to recheck the attributes.

We then talked about doing a CB to handle the object label notification:

1) Tom pointed out that not all Label changes would require revocation and
a smart client might want to either recache the attribute or make some
other decision.

2) David B. led the discussion that in the above scenario, a smart client
would detect and honor that it should stop access to the file.

3) David Q. raised the concern about clients not supporting the CB (a NFSv4.0
concern with sideband protocols). And Peter replied with NFSv4.1, they
went over the same established channel. In the end, we decided it was
the client implementation choice about to support the CB.

a) With a smart server that did revocation, no need to do CB then.
b) With a smart client and LNFS passing server, it is a requirement that
the client support CBs.
c) For updating cached attributes, it is a nice to have, not a must have.

+ DS needs to authenticate a subject label with the MDS.

The current model of verifying DAC and export permission is agnostic with
respect to Files, Objects, and Blocks. We decided to extend it to also
verify (and fence if necessary) the subject label.

+ Recalling a layout when an object label changes

Not discussed

+ Delegation support

Not discussed

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 29 Apr 2011 20:19:59 +0000

Thanks for the notes, Tom, and the participation everyone.

Can you outline next steps for this work?
Any identified deliverables (documents, email, etc.), owners
and any times that may have been associated with them?

Thanks,
Spencer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Friday, April 29, 2011 1:08 PM
To: [email-masked]
Subject: [nfsv4] [LNFS] Meeting Notes for 04/29/11

Attendees
--------------

Tom Haynes (NetApp)
Dave Quigley (davequigley.com<http://davequigley.com/>)
Jarrett Lu (Oracle)
Peter Staubach (EMC)
David Black (EMC)
Nico Williams (cryptonector.com<http://cryptonector.com/>)

Agenda
-----------

+ Use Cases

+ RPCSEC_GSSv3

+ Capabilities

+ Object label changes

A) Non-LNFS aware
B) LNFS passing
C) Smart

Not discussed

+ Delegation support

Not discussed

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 29 Apr 2011 15:38:36 -0500

> following scale of servers:

The draft defines this middle case:

6.5.  Simple security label storage

   In this case, a mixed and loosely administered network is assumed,
   where nodes may be running a variety of operating systems with
   different security mechanisms and security policies.  It is desired
   that network file servers be simply capable of storing and retrieving
   MAC security labels for clients which use such labels.  The Labeled
   NFS protocol would be implemented here solely to enable transport of
   MAC security labels across the network.  It should be noted that in
   such an environment, overall security cannot be as strongly enforced
   as in case (a), and that this scheme is aimed at allowing MAC-capable
   clients to function with local MAC security policy enabled rather
   than perhaps disabling it entirely.

---

From: Nico Williams <[email-masked]>
Date: Fri, 29 Apr 2011 15:49:25 -0500

> feedback, most notably David Black.

We await David's comments in response to my analysis regarding
interoperability and what is easy/hard to implement.

> We decided not to further explore capabilities for LNFS.

Capabilities are an optimization to cache (with the client's help) the
results of expensive access control decisions.  They can also avoid
the need for MDS<->DS communication regarding authorization.

Capabilities are orthogonal to LNFS, thus we dropped them from the
discussion for LNFS.  I would still like to encourage the WG to
consider capabilities.

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

Very good summary!

> c) For updating cached attributes, it is a nice to have, not a must have.

Also very good summary.  Much could have been lost.  Kudos on great note taking.

> [...]

s/authenticate/authorize/

no?  (yeah, total nit)

> + Recalling a layout when an object label changes

But surely an answer is implied by the above.  Clients that should
lose access, lose it (and experience, effectively, stale file handles,
with applications getting a local equivalent of SIGLOST).  Clients
that should keep it, keep it, at most learning of the change.

> Not discussed

Sam as above, no?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 29 Apr 2011 19:22:25 -0500

Also, while we decided that revocation should be immediate (no chance
for clients/apps affected to flush dirty buffers), we did not make a
decision as to whether there should be any sort of distinct revocation
operation, ala BSD4.4's revoke(2) system call.

---

From: Thomas Haynes <[email-masked]>
Date: Sat, 30 Apr 2011 12:26:19 -0500

> and any times that may have been associated with them?

1) Jarrett to report on what Trusted Solaris does when a MAC label is
changed on a local filesystem.

2) David Black to provide feedback on Nico's proposed text for
RPCSEC_GSSv3.

3) Nico to provide a new draft of RPCSEC_GSSv3:

a) XDR changes found by some implementation experience
b) Added client and server expectations, dependent on 2) above.

4) Tom to propose text to do the following:

a) Handle the CB and provide rational for the use with the 'Simple security label storage'
b) Describe the authentication process between the DS and MDS.

5) Tom, find some owners for items in https://github.com/loghyr/LabeledNFS/blob/master/issues.txt

a) Start mailing individual items to the WG.
b) See who responds.

---

From: Spencer Shepler <[email-masked]>
Date: Sat, 30 Apr 2011 18:01:39 +0000

Thanks for the list, Tom.  Looks like we are lining up for a great discussion at our meeting in Quebec.

Spencer

From: Tom Haynes <[email-masked]<mailto:[email-masked]>>
Date: Sat, 30 Apr 2011 12:26:19 -0500
To: Spencer Shepler <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nfsv4] [LNFS] Meeting Notes for 04/29/11

Thanks,
Spencer