Re: [nfsv4] Path forward for flex-files

[Benjamin Kaduk <[e-mail]>]

On Mon, Aug 07, 2017 at 11:03:44PM +0000, Rick Macklem wrote:
> Olga Kornievskaia wrote:
> [lots of stuff snipped]
> > 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.
> Oh, the reason I was thinking of using TGT tickets was related to my comment
> at the end about deleting the synthetic principal to do fencing.
> 
> I was thinking of a TGT with a fairly long lifetime (as long as layouts need
> to be valid) and a service ticket with a short lifetime, so that the client keeps
> using the TGT to get a new service ticket/GSS-context.
> Then, this would fail when the synthetic principal is deleted in the KDC.
> (I don't think that renewable tickets are needed, that was a brain fart on my part.)

The solution space looks rather different whether the synthetic principals
are actually being created/deleted on the KDC or synthesized using the
data server's keytab.  In the case where the KDC is involved, ticket
lifetimes and principal existence are somewhat annoying to manage -- in
order to have a long-lived TGT but get short-lived service tickets, with
(e.g.) an MIT krb5 KDC you'd either have to use a custom policy plugin to limit
the service ticket lifetime, or set the max lifetime on the data server's
service principal to that short lifetime (which has annoying effects for
anything that's supposed to be connecting to it directly).  As far as principal
management, the fencing would not be particularly instantaneous -- the
current ticket would have to expire, and the principal deletion/deactivation
would need to propagate to all KDCs in the realm.  IIRC it's also possible
to have a KDC that doesn't even pull up the client principal's database
entry when generating a service ticket from a TGT (i.e., it would not
actually notice the deleted client principal!), which of course would not
work for this use case.

-Ben