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

[Olga Kornievskaia <[e-mail]>]

On Mon, Jul 24, 2017 at 4:43 PM, Benjamin Kaduk <[e-mail]> wrote:
> 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.

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.