[OpenAFS] Preferred method for turning MIT Kerberos tickets into AFS tokens in Linux

[Ken Hornstein]

>If that came across as a disparaging remark then I apologize.  I didn't
>mean it that way.  I'm incredibly grateful to you Ken for your faq and
>aklog and so much more.  You've helped me a great deal both directly and
>indirectly.

No offense taken.  The situation is unfortunately more complicated than
I would have originally hoped, but in the long term it should be better.

The problem is that aklog has dependencies on _two_ external packages:
OpenAFS and MIT Kerberos.  Both of those packages have woefully
underspecified APIs.  MIT is better in this respect, but the important
API that we need there (524) wasn't even in an include file until
recently, and then it got a name change during that process.  And don't
even ask about writing autoconf tests for them.  This is better now that
people have standardized on the use of krb5-config, but I haven't had
time to fix everything up.  The other tools in the distribution are
unfortunately in worse shape; they require internal MIT APIs and include
files (some of which don't get built until you build MIT Kerberos, and
none of them get installed in any normal location; those APIs have
changed significantly).

So, what's happening with this in the long term?  Well, I've imported
aklog into OpenAFS (it doesn't built yet, but hey, it will).  fakeka
is now in MIT Kerberos.  I suspect asetkey should go into OpenAFS,
but I haven't talked to Derrick about it yet.  I haven't yet figured
out what to do with afs2k5db and ka-forwarder; ka-forwader could probably
go into OpenAFS, but afs2k5db is a tough one.

>I looked in 1.3.74 afs/cellconfig.h for the function prototype and it's
>true.  The prototype calls for 4 parameters and the code in asetkey.c
>calls the function with 3.  I looked in cellconfig.c for the function
>definition and it looked like it might be safe to just add a "0" as the
>fourth parameter to the function call in asetkey.c and this does get me
>an executable asetkey, but I have no idea if my change caused a logical
>error that will result in buggy behavior.  I really don't want to lose
>data.  Could someone here comment on the safety of that change?  Is
>there any risk of it causing file corruption or loss?

You won't have data loss if asetkey is bogus; the worst you'll get is
people won't be able to authenticate :-)  But it looks like to me that
adding a 0 as the 4th argument should be fine.

--Ken