[OpenAFS-devel] Re: [OpenAFS] New Windows AKLOG...

[Rodney M Dyer]

At 10:02 AM 7/23/2003 -0400, you wrote:

>Hey, I thought you were doing a "from-scratch, clean room implementation"? :-)

Shhhh!   Doh!  Ok, yea, the orginal code was "cleaned"...in a 
"room".  ;)  Yea, I'm using most of the original code, just buffed up real 
nicely for Windows.

I've noticed a couple of strange anomalies in the original code.  The first 
was related to the free'ing of the memory allocated by 
krb5_get_host_realm().  The krb5_xfree() call now causes a Debug assertion 
failure.  I noticed what seems to be a new call krb5_free_host_realm().  I 
used that instead and it solved the problem.  Was I correct in doing 
this?  It is strange that on older compiles of the original code with older 
Krb5 versions the krb5_xfree() worked correctly.

The second problem is related to checking of the existing token to see if 
it matches the new token to be set.  I found that this code never works...

if
(
         !force &&
         !ktc_GetToken(&aserver, &btoken, sizeof(btoken), &aclient) &&
         atoken.kvno == btoken.kvno &&
         atoken.ticketLen == btoken.ticketLen &&
         !memcmp(&atoken.sessionKey, &btoken.sessionKey, 
sizeof(atoken.sessionKey)) &&
         !memcmp(atoken.ticket, btoken.ticket, atoken.ticketLen)
)
{
         if (dflag)      fprintf(stdout, "Identical tokens already exist; 
skipping.\n");
         return 0;
}

The reason is in the line...

         !memcmp(atoken.ticket, btoken.ticket, atoken.ticketLen)

The token that is in the AFS cred cache always differs from the new token 
to be set because of the last 8 bytes of the credential.ticket_st.dat buffer.

What is going on with those last 8 bytes?


>That's fine with me; the people who's aklog mine is based on didn't care,
>and I certainly don't either.

Ok, so you are saying there are no export restrictions on the code or binary?

Thanks,

Rodney