Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

cburnett@us.ibm.com

Subject: Re: [nfsv4] Kerberos ticket expiration and NFSv4 state
Message-ID: <OFD6B3AAF1.5A4196EE-ON87256DB0.00631EE9@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Mon, 29 Sep 2003 13:21:32 -0500

Look below:

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:48 PM

        To:     "Noveck, Dave" <Dave.Noveck@netapp.com>
        cc:     nfsv4@ietf.org
        Subject:        Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

Noveck, Dave wrote:

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

Ok, fair enough.

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

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?

CARL: Trust me, its very normal, and many admins want client users to 
periodically recertify their authentication. A lot of effort went into DFS 
to try to deal with this and accommodate recertification w/o immediately 
reclaiming resources.

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.

Carl: Not acceptable. Admins don't have time to play with state at the 
server on behalf of thousands of clients and massive numbers of files.

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.

Carl: not necessarily if you consider the client is the responsible entity 
for the some of primarily state oriented ops, not the accessing user.

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

Carl: One of the reasons that months ago I proposed the idea of WRONGSEC 
returns on SETCLIENTID and SECINFO options to request a list of flavors 
the server accepts for SETCLIENTID. Then servers with strong client to 
server security requirements can enforce and communicate them to clients.

_______________________________________________
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