Coda File System

Re: stranger and stranger: ctoken goes away when I cd to /coda

From: Bradley C. Kuszmaul <bradley_at_GRANITE.SYSTEMSX.CS.YALE.EDU>
Date: Thu, 14 Aug 1997 16:38:43 -0400
   > OK, I'll try fixing the auth2.tk to be exactly 9 characters.  (It is
   > 16 characters right now.)

Well, I changed my auth2.tk to be exactly 9 characters, and I still
have my problem.  Enclosed is wallpaper and part of my SrvLog that is
relevant.  I guess I am stuck.  I can get a ctoken, but as soon as I
touch my /coda filesystem, the token evaporates.

I am also somewhat distressed to see how bad is the encryption used
for auth2.pw.   Characterwise xor with "drseuss "?  Bleah!
What protection is used for protecting the data in RPC calls?

-Bradley

--- wallpaper ---
bradley_at_pepes.cs.yale.edu>clog
Password: 
bradley_at_pepes.cs.yale.edu>ctokens

Tokens held by the Cache Manager:

UID=578 : [Expires Aug 15 17:32]
bradley_at_pepes.cs.yale.edu>cd /coda
bradley_at_pepes.cs.yale.edu>ctokens

Tokens held by the Cache Manager:

UID=578 : Not Authenticated
bradley_at_pepes.cs.yale.edu>
--- end of wallpaper ----
part of SrvLog is here:

16:32:58 LockQueue Manager woken up
16:32:58 LockQueue Manager sleeping for 60 seconds
16:33:01 Could not get a valid key in GetKeysFromToken
16:33:02 Worker 4 received request -13 on cid 14 for NA at NA
16:33:02 in AL_GetInternalCPS(-101, 0x831c54c)
p_TypeOfEntry: GROUPDEF
p_Name = "System:AnyUser"    p_Id = -101    p_Owner = 777
p_List1Bound = 0    p_List1Count = 0
p_List1 = ()
p_List2Bound = 0    p_List2Count = 0
p_List2 = ()
p_List3Bound = 0    p_List3Count = 0
p_List3 = ()
p_PlusBound = 10    p_PlusCount = 1
p_Plus = ( (777  -1) )
p_MinusBound = 0    p_MinusCount = 0
p_Minus = ()

16:33:02 New connection received RPCid 14, security level 98, remote cid 136941656 returns Success
16:33:02 Worker 5 received request 40 on cid 14 for bradley at 80240bcc
16:33:02 ViceConnectFS (version 1) for user UID=00000578 at pepes.cs.yale.edu.venus
16:33:02 ViceConnectFS returns Success
16:33:02 Worker 0 received request 38 on cid 14 for bradley at 80240bcc
16:33:02 ViceValidateAttrs: Fid = (7f000000.1.1), 0 piggy fids
16:33:02 ViceGetAttr: Fid = (7f000000.1.1), Repair = 0
16:33:02 ValidateParms: 7f000000 --> b4000001
16:33:02 Entering VGetVolume for volume b4000001
16:33:02 VGetVolume: nUsers == 0
16:33:02 VGetVolume: Calling AvailVolumeHeader()
16:33:02 Entering AvailVolumeHeader()
16:33:02 AvailVolumeHeader returns 1
16:33:02 VGetVolume: Calling GetVolumeHeader()
16:33:02 Entering GetVolumeHeader()
16:33:02 GVH: setting hd->prev->next = 
16:33:02 82042b8
16:33:02 GetVolumeHeader: hd->next = 0x82042b8, hd->prev = 0x8204540
16:33:02 GetVolumeHeader: hd->next->prev = 
16:33:02 0x8203b20
16:33:02 VGetVolume: Finished GetVolumeHeader()
16:33:02 VGetVolume: partition name for volume b4000001 is /vicepa
16:33:02 VGetVolume: vp->device = 2071, disk.device = 2071
16:33:02 GetVolObj: returns 0
16:33:02 Entering VGetVnode(vol b4000001, vnode 1, lock 1, ignoreIncon 0)
16:33:02 VGetVnode: newHash = 2, vp = 0x8220800, vnodeNumber = 1 Unique = 1
16:33:02 Entering VBumpVolumeUsage for volume b4000001
16:33:02 AddCallBack for Fid 0x7f000000.1.1, Venus 80240bcc.21253
16:33:02 PutObjects: Vid = b4000001, errorCode = 0
16:33:02 Entering VPutVnode for vnode 1
16:33:02 Entering StickOnLruChain for vnode 1
16:33:02 Entering VPutVolume for volume b4000001
16:33:02 Entering ReleaseVolumeHeader
16:33:02 PutObjects: returning Success
16:33:02 ViceGetAttr returns Success
16:33:02 PutObjects: Vid = 0, errorCode = 0
16:33:02 PutObjects: returning Success
16:33:02 ViceValidateAttrs returns Success, 0 piggy fids checked
Received on 1997-08-14 16:58:57