Re: [securenfs-devel] Condensing Tokens on Client

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

Nathan Yocom wrote:
> Dave Wolff Wrote:
> ==============
> Which brings up another point.  Say localUserA logs in and gets a token
> for remoteUserA.  Then localUserB logs in and is mapped to the
> same remoteUserA.  localUserB should then need to provide the
> password for remoteUserA, and once authenticated would get a seperate
> token.  Now, the server doesn't know the difference between localUserA
> and localUserB, he doesn't need to.  So should we have two different
> tokens or just a single token shared by both?
> 
> ============
> 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?

Dave

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