Re: [securenfs-devel] Condensing Tokens on Client

[David W. <wo...@pl...>]

Nathan Yocom wrote:
> David Wolff wrote:
> 
>>> Good question.  Other than making sure we invalidate the token when 
>>> there are no more connections as a particular user, I can't think of 
>>> issues either way.  It could be we actually hand't decided that yet 
>>> ;-) If we write something like:
>>>    uid:token:mnt_pt
>>> to the /proc/ system, then we could almost just say in the pam module 
>>> "if uid exists in /proc, dont re-write the uid:token, just verify the 
>>> username and password and immediatley invalidate the token from the 
>>> server"  - So the server would respond to the second login with a 
>>> token, that token would be invalidated, and the client would use the 
>>> existing token for further communication.
>>>
>>
>> Couldn't the server just respond with the first token?
> 
> 
> Makes sense.  We could have the server maintain a count (ala counted 
> spinlocks) on the token and simply increment for requests originating 
> from the same host:username:password and decrement for every invalidate 
> command from host:username - when count == 0 then we remove the token 
> from the list.
> 
> ?
> 

Yep.  Just what I was thinking.  That avoids the
messy invalidation step.

Dave



-- 
----------------------------------------------------------------
I encourage correspondence using GnuPG/OpenPGP encryption.
My public key:  http://www.cs.plu.edu/~dwolff/pgpkey.txt