Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

cburnett@us.ibm.com

Subject: Re: [nfsv4] Kerberos ticket expiration and NFSv4 state
Message-ID: <OF2243EAB8.71F1B2D1-ON87256DB0.00652DAA@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Mon, 29 Sep 2003 13:40:04 -0500

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 01:04 PM

        To:     Carl Burnett/Austin/IBM@IBMUS
        cc:     nfsv4@ietf.org
        Subject:        Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

Carl Burnett wrote:

> I think this is independent of Erik's discussion and the state id 
recovery

We disagree then.

[Carl: Let me try again. As a result of expired authentication, a client 
may have to replay requests. So in that sense the retry stuff applies. But 
the subject of authentication requirements for operations like CLOSE and 
LOCKU has a been presented is a different aspect that is not fully 
addressed by the retry discussion and lessons in Erik's document.
]

> 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 

Why?

> even a different auth flavor. Both CLOSE and LOCKU could be viewed as 

Only if the server allows multiple auth flavors per objects.
If it doesn't, it will be the same authentication flavor.

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

At the cost of reduced security? User's of NFS won't (and don't)
expect this, and are surprised that this is how it works with NLM
and NFS.

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

NFSv4.0's authentication model is user to server, not
client host to server. If we want to have a different
model, that's NFSv4.next (or NFS w/ AUTH_SYS).

[CARL: DFS was primarily user to server too. But certain aspects were 
client host to server. Not really that different from the fact that in NFS 
V4, SETCLIENTID is in fact client host to server. DFS just had a wider set 
of operations that fall into that category. As Dave N. stated earlier, it 
may be more of an effect of the NFS spec not stating specifics on some of 
these interesting cases like CLOSE and LOCKU where the primary effect of 
the operation is state management, not file resource access or 
manipulation. LOCKU of course straddles on both a bit.
]

_______________________________________________
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