Subject: [nfsv4] comments w.r.t. flex layout draft 12

From: Rick Macklem <[email-masked]>
Date: Fri, 21 Jul 2017 21:41:40 +0000

Hi,

Overall, it looks good to me.

First off, there is one generic issue I thought I'd bring up...
- w.r.t. Kerberos...shouldn't it be talking about Rpcsec_gss instead of Kerberos,
  just in case someone uses another security mechanism someday?
- Also, I'll admit I didn't understand the last two sentences of Sec. 15.1.1.
 - Why is the metadata server generating TGTs. Is this referring to the case of
   the metadata doing I/O on the storage server? Or is this specific to some part of
   RPCSEC_GSS_V3 (which I'll admit I've never looked at;-). If the latter, just ignore
   my ignorance;-)

Now, here are the minor typo like things I spotted. (Feel free to ignore any you
disagree with):
344:   wrong credential for the deisred access will get a NFS4ERR_ACCESS
- spelling of "desired"

855:   ... Note that
856:   even if the data protocol is at least NFSv4.1, it may still be the
857:   case that there is loose coupling is in effect.  If
- one too many "is"? -->"there is loose coupling in effect."

957:   This document defines structure associated with the layouttype4 value
- "structures" (ie. plural)?

1105:   If an implementation needs a different statedid per file handle, then
- spelling of "stateid"

1166:   with a LAYOUTEGT which returns an error of either
- spelling of "LAYOUTGET"

1326:   ... While the client
1327:   may provide a hint to how many copies it wants (see Section 12), the
- "hint as to how many"
1328:   metadata server can ignore that hint and in any event, the client has
1329:   no means to dictate neither the storage device (which also means the
- "dictate either the"

1349:   (see Section 8.2.  If the client is writing to the layout segments
- closing ")"

1374:   ... The requirements for writing to a mirrored layout
1375:   segments are presented below.
- single or multiple layouts? "a mirrored layout segment" or "to mirrored layout segments"

1387:   client then MUST inform the metadata server (see Section 8.2.3.  The
- closing ")"

1472:   been done, and these data must have been committed to stable storage
- "and the data must"

2039:   modifying the syntethic uid or gid on the data file.
- spelling of "synthetic"

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 24 Jul 2017 15:43:55 -0500

>   just in case someone uses another security mechanism someday?

Arguably it should, yes.  But the GSSAPI way to do the sort of thing
needed here involves GSS_Export_sec_context/GSS_Import_sec_context, which
is formally only specified for interprocess transfer on a single machine.
(After all, GSS-API objects are permitted to be opaque handles referring
to data stored outside of the current process.)  Some implementations
do just dump a serialized data structure that could in theory be sent
over the network and used elsewhere, but there is no standardized way to
do so.  Kerberos tickets, on the other hand, are standardized and quite
interoperable.  But the specification might do well from using more general
terms and only listing Kerberos tickets as an example.

>    RPCSEC_GSS_V3 (which I'll admit I've never looked at;-). If the latter, just ignore

My (admittedly hasty) reading was that the metadata server is generating
"credentials" that the client then uses in subsequent communication with
the data server.  Those newly minted credentials ought to be limited to
just the file access that was indicated to the MDS, whether by having
a dedicated/throwaway client principal name akin to the synthetic uid/gid
schemes, authorization data in the ticket, or some out-of-band scheme.
In order to fit nicely into the existing deployments using Kerberos,
the minted credentials need to be Kerberos credentials.

That said, I see no reason why they need to be a TGT -- a service ticket
for the data server principal would work just fine and would save the
client a round-trip to the KDC.  Doing so would also provide a bit more
implementation flexibility, if the MDS is given access to the long-term
key of the data servers (as it could then just print tickets locally and
not need to interact with the KDC).  Another option for this sort of thing
would be the S4U2Proxy extension, that lets the MDS request that the KDC
print the desired tickets and the KDC can do authorization checking and
apply restrictions to the generated tickets/etc.

-Ben

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 24 Jul 2017 21:22:46 +0000

> On Jul 24, 2017, at 1:43 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Arguably it should, yes.

My bad - too much caffeine and not enough sleep. I knew I should
not have been writing down the word “kerberos”.

I’ll tie this back into Section 1.7.1 of RFC 5661.

>  But the GSSAPI way to do the sort of thing

Thanks for the suggestion, I’ll try to write this in to the next draft.

My main concerns here were:

1) Having sufficient requirements to meet the ones we have at the standards body level.
2) Giving enough detail that it did not look like hand waving.
3) Not lock an implementation down.

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

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 24 Jul 2017 21:32:29 +0000

> On Jul 21, 2017, at 2:41 PM, Rick Macklem <[email-masked]> wrote:
> 
> Hi,
> 

Just pointing that I’ll deal with this in the context of the emails from Ben and Olga.

And I’ll address the nits in my next editorial round.

Thanks for taking the time to do the review!

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 25 Jul 2017 13:05:49 -0400

> apply restrictions to the generated tickets/etc.

S4U2Proxy helps if MDS was the one wanting to "act on users request"
to the storage server. However, in this case (in this proposal), MDS
is the one creating a new "identity" (synthetic uid/synthetic Kerberos
principal) for the user to use while the client is authenticating to
the storage server.