(Illustration by Gaich Muramatsu)
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. JanReceived on 2000-04-24 20:24:58