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

[Benjamin Kaduk <[e-mail]>]

On Fri, Jul 21, 2017 at 09:41:40PM +0000, Rick Macklem wrote:
> 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?

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.

> - 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;-)

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