On Mon, Apr 24, 2000 at 08:22:45PM -0400, Jan Harkes wrote:
> Strange, it looks like the kerberized authentication failed to get a token.

No, but there is something strange.  Here is gdb on kclog, with a
breakpoint set in WriteTokenToFile, run as 'r -tofile /tmp/tok':

Breakpoint 1, WriteTokenToFile (filename=0xbffffdef "/tmp/tok",
    cToken=0xbffffc10, sToken=0xbffffc34 "") at tokenfile.c:51
51          len = sizeof(ClearToken) + sizeof(EncryptedSecretToken);
(gdb) print *cToken
$1 = {AuthHandle = -1, HandShakeKey = "\\rs\xb6"\002\213S", ViceId = 102,
  BeginTimestamp = 0, EndTimestamp = 956744530}
(gdb) n
52          buf = malloc(len);
(gdb) print len
$2 = 80

So, although sToken appears to be a null string, cToken is there
and seems to make sense, at least to some extent.  The variable len
does have a positive value, contrary to what I thought, but

59          fputs("*** Coda Token ***", f);
(gdb) n
60          base64_encode(f, buf, len);
(gdb) print len
$3 = 80
(gdb) c
Continuing.

     Program exited normally.
     (gdb) q
     avl 10:24:14 > ll /tmp/tok
     -rw-------   1 root     root           18 Apr 25 10:24 /tmp/tok

This appears to show that the function base64_encode is not writing
anything.  Still:

     avl 10:24:17 > ctokens

     Token held by the Cache Manager:

     Local uid: 0
     Coda user id: 102
     Expiration time: Wed Apr 26 11:22:10 2000

So I _am_ getting a token.

On further investigation, I find one of the kerberos libraries
includes this function:

     int base64_encode(const void *data, int size, char **str);

and this is obviously the problem.  Namespace pollution!

Ok, I've now defined base64_encode and base64_decode to something
else for coda, and recompiled.  I now get

     avl 11:03:15 > kclog -tofile /tmp/tok
     username: root

     Date: Tue 04/25/2000

     11:03:19 In Krb5Init()
     avl 11:03:19 > ll /tmp/tok
     -rw-------   1 root     root          129 Apr 25 11:03 /tmp/tok
     avl 11:03:22 > cunlog
     avl 11:03:26 > kclog -fromfile /tmp/tok
     username: root
     avl 11:03:33 > ctokens

     Token held by the Cache Manager:

     Local uid: 0
     Coda user id: 102
     Expiration time: Wed Apr 26 12:03:19 2000

At least in the short term this fixes my problem.  But tokentool
still doesn't work.

     -- Owen
     LeBlanc_at_mcc.ac.uk