Re: [nfsv4] Path forward for flex-files

[Rick Macklem <[e-mail]>]

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