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

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 29 Sep 2003 10:32:20 -0700

> > Imagine an application started by a Kerberos-authenticated
> > user that has a
> > byte-range lock on a file.  If the ticket expires and the application
> > attempts to unlock, close and exit, neither the LOCKU nor the
> > CLOSE will be
> > allowed at the server because of the expired ticket.  Since
> > the client must
> > allow the application to close and exit, it should probably
> > clean up the
> > state.  However, now the client and server have different views of the
> > state.  In fact re-running the same application on the client

> Not at all. The client is well aware that the attempt to
> unlock the file has failed. Isn't this just a variation on
> the theme described in:
>
>	http://www.connectathon.org/talks03/eric.pdf

It is a variation but there is a significant difference (a difference
is what makes it a variation after all :-).  In this case, we can't
simply redo the request to find out whether the first time succeeded
since the ticket expiration prevents that.

> > will result
> > in a lock conflict due to the stale lock on the client.  Assuming the
>
> If you can re-run the application, then it must have been able
> to get a new ticket. Thus the client, because it is
> aware it has a lock, can now unlock.

Makes sense to me.

> > client is able to continue to renew its lease, I see no way
> > this will ever
> > get cleared up short of a  SETCLIENTID by the client with a
> > new verifier.
>
> If lease is not renewed before lease expiration, then the lock
> goes away either when the lease expires, or when a conflicting
> lock is requested by the client or a different client.

But the hypothesis here is that the lease will be renewed because
other users, who have valid unexpired credentials, will do locking
requests that renew the lease associated with all of the locks for
that client, which also include those associated with the expired
credentials.  So given that renewal is continuing to occur, the question
is how the locks associated with the expired credential can be gotten
rid of.  It won't happen solely due to lease expiration. 

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

---

From: Mike Eisler <[email-masked]>
Date: Mon, 29 Sep 2003 10:48:21 -0700

> other users, who have valid unexpired credentials, will do locking

Ok, fair enough.

> rid of.  It won't happen solely due to lease expiration. 

And I'm having trouble accepting that this is normal scenario.
Why wouldn't the client automatically renew his ticket?
If another kinit is required, why wouldn't the user be motivated
to issue one?

Worst case, you get rid of the lock via a management interface,
just as some NFS servers today provide the means for
clearing locks the client has apparently forgotten about.

If there are clients that acquire locks without an acceptable
strategy for renewing tickets, then they'll have to issue one
SETCLIENTID per Kerberos principal.

Hmm, maybe we should have side bad locking protocol that
always listens over AUTH_SYS. Oops, we tried that
already. :-)

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 29 Sep 2003 12:15:35 -0700

> >other users, who have valid unexpired credentials, will do locking

On multi-user systems it's not unreasonable to expect that hostbased
credentials will be available.  (In the Kerberos V case such credentials
are even necessary if one wishes to authenticate users logging into the
client with Kerberos V network authentication or password validation.)

> If another kinit is required, why wouldn't the user be motivated

User locks screen, [removes smartcard from reader,] goes on vacation,
creds expire, dirty data / locks cannot be flushed / unlocked.  Oops.

Even if there's a hostbased credential available the dirty data may not
be writable (the host may not have the necessary permissions).

The use of channel bindings to bind multiple client principal's GSS
contexts to the same underlying "session" (even the CLIENTID) would
help.  CCM and all that...

> clearing locks the client has apparently forgotten about.

Sure.

> SETCLIENTID per Kerberos principal.

Yeah, one CLIENTID per user may work.

Cheers,

Nico
--