RE: [nfsv4] Kerberos ticket expiration and NFSv4 state

cburnett@us.ibm.com

Subject: RE: [nfsv4] Kerberos ticket expiration and NFSv4 state
Message-ID: <OF16298507.98838EBD-ON87256DB0.006035A5@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Mon, 29 Sep 2003 12:42:57 -0500

I think this is independent of Erik's discussion and the state id recovery 
stuff. As Dave Noveck hinted, the server is going to need to allow LOCKU 
and CLOSE independent of the authentication used. Truth is the application 
close at the client that represents last close isn't necessarily the one 
that did the open. I could be using a different authentication context or 
even a different auth flavor. Both CLOSE and LOCKU could be viewed as 
"client wide" management, and therefore maybe the client should just use 
what ever authentication model it used with SETCLIENTID. Perhaps the 
server should ignore the authentication or just check that is the same 
authentication that was used in SETCLIENTID.

If its of any relevance, this in concept is how DFS (and AFS minus 
locking, which it did not really have) viewed the management of open and 
byte range locking related state. State management was a "client 
authenticated model", not per user. Credential expiration and related 
failures for normal users was one of the factors in this. Also, you cannot 
assume a credential expiration or security related failures for a 
user/application will ever be resolved.

Carl

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

Mike Eisler <mike@eisler.com>
Sent by: nfsv4-admin@ietf.org
09/29/2003 12:19 PM

        To:     nfsv4@ietf.org
        cc: 
        Subject:        RE: [nfsv4] Kerberos ticket expiration and NFSv4 state

 > 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

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

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

 > The problem with this is that other users on the same client
 > who may still
 > be authenticated and have their own state will have their
 > state blown away
 > on the server by the SETCLIENTID.
 >
 > What's a client to do?
 >
 > David W. Sheffield
 > sheff@us.ibm.com
 > (512)838-3535
 >
 >
 > _______________________________________________
 > nfsv4 mailing list
 > nfsv4@ietf.org
 > https://www1.ietf.org/mailman/listinfo/nfsv4
 >

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4