On Mon, Apr 24, 2000 at 08:59:12AM +0100, Dr A V Le Blanc wrote:
> I thought before that kclog was segfaulting; at any rate, it does
> not do so now.  Instead I see this:
... 
> In other words, kclog is successfully getting a coda token, but
> not writing it correctly to the token file, which contains nothing
> but '*** Coda Token ***'.  Not surprisingly, when you try to reload
> this file using klog:
> 
>      avl 08:52:14 > kclog -fromfile tok zlsiial
>      username: zlsiial
>      Corrupted token file?
>      Segmentation fault
> 
> It doesn't work.  Looking at the source:
> 
>          fputs("*** Coda Token ***", f);
>          base64_encode(f, buf, len);
> 
> it looks as though the value of 'len' here is 0?

Strange, it looks like the kerberized authentication failed to get a token.

> I notice that there is in the same source directory a program tokentool
> for creating arbitrary tokens:
> 
>      avl 08:56:33 > ./tokentool
>      ViceID                   ? 102
>      Token validity (hours)   ? 24
>      Shared secret (auth2.tk) ? /vice/db/auth2.tk
>      Output token file name   ? /tmp/tok
> 
> This produces a file 129 bytes long.  But:
> 
>      avl 08:57:13 > kclog -fromfile /tmp/tok zlsiial
>      username: zlsiial
>      Corrupted token file?
>      Segmentation fault
> 
> This too produces a fault when loading.  Should -tofile and
> -fromfile work with kerberised Coda?

Yes, they should work fine, in fact the whole kerberized authentication
is skipped when running 'clog -fromfile'. I also wonder how it can
segfault after printing "Corrupted token file?":

    if (len != (sizeof(ClearToken) + sizeof(EncryptedSecretToken))) {
        fprintf(stderr, "Corrupted token file?\n");
>>      free(buf);  	<< crashed here?
>>      exit(-EINVAL);  << or here?
    }

Maybe it failed to open /tmp/tok, or failed to successfully decode the
contents, but the buffer is always allocated in base64_decode, and exit
shouldn't really have a problem with -EINVAL.

Jan