Re: [nfsv4] Path forward for flex-files

[Benjamin Kaduk <[e-mail]>]

On Sat, Aug 05, 2017 at 09:18:50AM -0400, David Noveck wrote:
> I've been holding off on doing a detailed review of flex-files-12 since Tom
> has previously indicated there would be -13.
> 
> I've been following the discussion of the details of loose-coupling
> security, but my lack of understanding of Kerberos meant
> that most of the discussion went over my head.  However, I think it is
> pretty clear that if Olga doesn't think the approach in -12
> will work and Tom agrees, then it won't work and I'm glad we are moving
> on.  I don't think that the deletion of RPCSEC_GSS

I also agree with Olga and Tom -- there just isn't the proper (opaque)
hole in which to stuff the needed data, and the XDR is already in the wild.

If one was super-desparate, one could imagine running a separate service
on the MDS that maintained a database of synthetic uid/gid against the
GSS entity that's authorized to access that file, and issues the synthetic
GSS credentials.  But that doesn't really help us here, since there would
need to be a whole separate protocol specified for this separate service,
all entities would need to know it's in use, etc..  It doesn't seem worth
trying to graft properl RPCSEC_GSS support onto flex-files within the
constraints of the current XDR; I'm sorry I didn't notice that in my
earlier review, and thanks to Olga for pointing it out.

> support for loose-coupling will be an issue for the IESG, since there is
> support for this when used with tight couplling.
> 
> I'd like to see this document and layout-types go forward in the near
> future and my initial comments will focused on making
> sure that that happens.  Later I'll discuss the issues with regard to the
> future work that Tom is thinking about.
> 
> As I understand things, -13 will include the changes that Chuck has
> suggested to tie this document more closely to layout-types
> and I think that's a good thing. When that change is made, it will need to
> address the fact that these two documents define the
> term "control protocol" differently, although there probably aren't
> differences in actual usage to address.
> 
> As far as I am concerned, there is no need for another WGLC cycle for
> layout-types-06, although Chuck (or others) might feel differently.
> 
> If we consider the longer-term perspective including the work Tom has
> discussed, it seems to be that we have to decide on
> how to divide the following items into RFCs:
> 
>    1. The definition of the XDR for the initial flex-files layout type
>    (currently FLEX_FILES but I think FLEX_FILES_v1 should be considered) along
>    with registration request for it.
>    2. The registration request for the follow-on layout type, FLEX_FILES_v2
>    (I briefly considered FLEXIER_FILES but somhow, sanity returned :-).  This

Can I suggest putting in a typed opaque auth blob instead of explicit
synthetic uid/gid fields?  Then if someone actually wants to implement
one of these crazy loosely-coupled RPCSEC_GSS schemes (Rick's seems like
it would work fine, and I had a couple as well), they can write a spec
and allocate a new type to use for it.

>    one would not have an explicit RFC # but I believe that there is a way
>    around that to create some sort of early registration with an RFC to be
>    named later.
>    3. The XDR corresponding to the follow-on layout type.
>    4. The framework allowing co-operation between MDS and client to
>    implement RPCSEC_GSS for loose coupling.  I expect this would allow use of
>    RPCSEC_GSSV3 but see no need to say  so explicitly.

Er, right, that.

>    5. The actual coordination scheme that Tom wants to standardize.
> 
> If this organization of the work does not make sense or is missing
> something, please let me know.
> 
> I anticipate that the initial flex-files RFC would include 1) and 2).
> 
> The reasons that I don't want to include 3) are:
> 
>    - 3) doesn't make much sense without 4) and adding 4) would push the RFC
>    off a while.
>    - There's a small possibility further XDR issues will arise so we might
>    as well avoid committing to a specific XDR until we have to.
> 
> It might make sense to do 3), 4) and 5) together but Tom might want to
> divide these into multiple RFCs.

I have no particular preference on that.

-Ben