Subject: Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

From: Mike Eisler <[email-masked]>
Date: Mon, 29 Sep 2003 13:13:52 -0700

> On Mon, Sep 29, 2003 at 02:53:56PM -0400, [email-masked] wrote:
>> [stuff clipped out, Mike wrote]
>> Like Dave, it seems to me that the principal that is allowed to do
>> a SETCLIENTID should also be allowed to do other state related Ops that
>> release state, such as LOCKU and CLOSE (I'm not so sure about LOCK,OPEN,...).
> 
> And writes (e.g., dirty blocks but no unexpired creds to write them with)?

In theory. In all the years I supported an NFS client that
had AUTH_DH support, I never had a customer call for this. If it were
ever called in, I'd have changed the client to force dirty blocks
out when expiration was near, and there after go in synchronous mode
until the context was renewed.

I believe the NFSv4 RFC discusses related issues with delegations and
RPCSEC_GSS context expiration ... i.e. return 'em if you won't be able
to later.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 29 Sep 2003 13:16:07 -0700

> RPCSEC_GSS context expiration ... i.e. return 'em if you won't be able

Right.  I think this a good strategy - the application doing the writing
will find out about the expired credentials problem synchronously
(though it will probably be unable to do much about it).

It would still be nice for clients with hostbased princs/creds to be
able to flush dirty data using the clients' hostbased creds, which
requires binding of the clients' contexts to the same quantity.

This reminds me: we have to finish up CCM.

Cheers,

Nico
--