Re: [nfsv4] Path forward for flex-files

[Olga Kornievskaia <[e-mail]>]

On Sun, Aug 6, 2017 at 5:14 PM, Rick Macklem <[e-mail]> wrote:
> My Kerberos/RPCSEC_GSS is pretty rusty, but I think the following is a rough
> description of something that might work for the "loose coupling" case.
> (And now I finally know why the old draft referred to TGTs.;-)
>
> First, I'll note that fattr4_owner and fattr4_owner_group isn't defined anywhere

dot-x defs: https://www.rfc-editor.org/rfc/rfc7531.txt

   typedef utf8str_mixed   fattr4_owner;
   typedef utf8str_mixed   fattr4_owner_group;


> and, if you just define is a opaque<>, with either "user@domain" or "<numeric-id>"
> in it for the AUTH_SYS case, I doubt you will have to rev. the XDR. (Which makes the
> path forward easier for us lazy implementors;-)
>
> Anyhow, here goes...
> Here's one way I think a "loose coupled" Flexible File Layout pNFS service
> could use Kerberos/RPCSEC_GSS.
> A few assumptions:
> 1 - The DS systems are vanilla NFSv3/4 servers that have Kerberos/RPCSEC_GSS
>     support in them.
> 2 - This is Kerberos specific, which seems ok, since all extant servers
>     will only support Kerberos mechanism.
> 3 - The MDS can somehow:
>     - Create/delete entries from the password database (assuming DS servers
>       implemented using POSIX-like users/uids/gids).
>       (I know nothing about LDAP, but I'd guess this is doable?)
>     - Create/delete User principals in the KDC with passwords that the
>       MDS will know/set when these principals are created.
>
> The MDS would create a synthetic user/uid/gid, adding it to the password
> database. It would create an associated User principal of the same name
> in the KDC.
> - It would then acquire a "forwardable, renewable" TGT for this principal.
> It could use this TGT to acquire an RPCSEC_GSS context for the DS, so it
> could perform RPCs as this synthetic "user" against the DS.
>
> When a client requests a layout:
> - The MDS would reply with the TGT for the synthetic user in fatt4_owner, after

That's the problem you need something in the structure to pass back
the ticket (TGT is not necessary. service ticket would do). Besides
the ticket you need to send the other pieces.

>   encrypting it in the key for the RPCSEC_GSS context that the client has against the
>   MDS for its LayoutGet RPC. (ie. It would GSS_Wrap() the TGT.)
>   --> This is similar to what happens when a Kerberos client does a "kinit",
>       except the ticket has been encrypted in the RPCSEC_GSS context key
>       (which it knows) instead of a key based on the principal's password
>       (which the client does not know).
>
> The client takes the GSS_Wrap()'d TGT. GSS_Unwrap()s it and puts it in a
> credential cache for the "synthetic user". (My Kerberos is rusty, so I can't
> remember if the principal name is in the TGT? If not, it needs to be sent
> along with the TGT to the client in the Layout.)
>
> The client can then do the normal RPCSEC_GSS Init sequence against the DS
> to get a context for the synthetic user. It can then use this context for
> I/O RPCs against the DS.
>
> If the Kerberos tickets have a short lifetime, but are renewable for a long
> time, the RPCSEC_GSS context timeout will normally be set to that short
> ticket lifetime and the client will regularily do the RPCSEC_GSS Init sequence again
> to get new contexts.
> --> This means that, once the MDS deletes the synthetic principal from the KDC,
>     it won't work for long against the DSs, I think?
>     (Deleting the principal from the KDC may be useful for fencing off, see
>      below.)
>
> I think the "gid" can be handled by using a second "synthetic principal" handled
> in the same manner. (ie. It would not "own" the file but would have the "gid"
> of the group for the file in the password database.)
>
> One problem I see with is that the MDS may need "root" access to
> the DS, if it is going to do fencing via a change in ownership.
> (I think this is doable using Kerberos, but certainly weakens security.
>  Something like putting a "root@REALM" user principal in the KDC and
>  generating a keytab entry for it for the MDS. But having a keytab entry for
>  "root@REALM" is pretty scary;-)
> - An alternative that might be worth considering would be to have the MDS delete
>   the synthetic principal in the KDC, so that clients can no longer use it to access
>   the file on the DS?
>
> rick
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4