Bradley,

I am not sure if this is the last message you have exchanged with Josh,
but I thought I would try to help. 

Let me first of all tell you about our plan for security:
1) Coda cannot use any encryption by default since then we cannot export
it.
2) There are almost trivial hooks we can change to use DES encryption and
kerberos tickets instead of auth2 tickets and this is being worked on for
USA release.
3) RPC2 is very similar to Kerberos 5 as far as security goes and can
encrypt all traffic strongly.
4) there is a variety of data collection and debugging tools which are not
secure that need modification/removal. 
5) The linux kernel code lacks one feature at the momemnt related to
security -- I hope to fix this before too long.

So we hope to become quite secure, but aren't there yet.

Another thing is that all the authentication and security seems confusing
but is in fact quite well thought out.  It is documented in 
Integrating Security in a Large Distributed System
M. Satyanarayanan
ACM Transactions on Computer Systems, Vol 7, No 3, Aug 1989, 247-280.

Back to your logs. The Server log you sent is interesting because it
shows:

> 16:33:01 Could not get a valid key in GetKeysFromToken

This routine is executed as part of the binding, and you see that RPC call
being made in venus/user.cc, line 437.  This file also immediately shows
that your token will be dropped if the server returned an error. This
explains why you have lost your token.

It seems pretty clear that all trouble is on the server, where the call
GetKeysFromToken is failing. 

It would be interesting to know what the flow of control is in the routine
GetKeysFromToken (auth2/avice.cc):

If you built your own srv (for example by rebuilding the rpm then there is
a srv with debugging symbols in
/usr/src/redhat/build/coda-4.1.2/coda-src/vice
If you fire that up and attach gdb to it, could you put a break on 
GetKeysFromToken
and tell me how you flow through the routine:
 1) is Key1IsValid True of False
 2) does the decryption fail

I have a feeling that rebuilding your password database with initpw -p
.... and then restarting srv should help too.  I hope this helps.

- Peter -

On Thu, 14 Aug 1997, Bradley C. Kuszmaul wrote:

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