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
