[OpenAFS-devel] patches for afs-krb5 (fix 64-bit bug, etc)

Christopher Allen Wing wingc@engin.umich.edu
Mon, 17 May 2004 21:18:33 -0400 (EDT)


Hello,

I don't know if there is a more current source for the krb5 migration kit
other than:

	http://grand.central.org/dl/contrib/security/particular-krb5/

(and if there is a better mailing list for me to send this to, please
let me know)


I needed to change a few things in order to build aklog on AMD64 Linux (in
particular, Fedora Core 1). Here are five proposed patches.



autoconf fixes:

1. res_search can be a macro (i.e. on recent linux glibc, AMD64). I just
copied the workaround for this out of the openafs source tree:

	http://www-personal.engin.umich.edu/~wingc/aklog/patches/1-res_search.patch

2. Some systems use libcom_err as a shared library; in this case,
add_to_error_table() is already provided and we don't need to build it
ourselves:

	http://www-personal.engin.umich.edu/~wingc/aklog/patches/2-com_err.patch

3. It looks like MIT krb5-1.3 no longer includes a separate libkrb524, but
instead moved the krb524 functions into libkrb5. Handle this:

	http://www-personal.engin.umich.edu/~wingc/aklog/patches/3-krb524.patch


(Those autoconf changes are sufficient to build aklog and asetkey on
Fedora Core 1, AMD64, but I haven't tested them on other systems, so I
wouldn't suggest applying them to the master source yet)


4. Here's a patch to fix some compiler warnings (wrong prototypes, missing
#includes, wrong format strings, etc.):

	http://www-personal.engin.umich.edu/~wingc/aklog/patches/4-warnings.patch



5. And finally, here's an actual bug. krb5_build_principal() is a varargs
function that expects a list of string pointers, terminated by a final
NULL. The original aklog code used '0' instead, which is passed as an int
and not automatically promoted to a pointer (as would be the case if it
was specified for a fixed argument). On a 64-bit machine, this results in
pushing a 32-bit value onto the stack instead of the expected 64-bit
pointer. So krb5_build_principal() never finds the terminating null and
starts following invalid pointers.

The fix is to use NULL, not 0. I also changed several instances of
'#define NULL' in some other files to use (void *)0 for correctness.
(although most systems should provide this anyway)

	http://www-personal.engin.umich.edu/~wingc/aklog/patches/5-64bit.patch



These changes are sufficient at least to build the OpenAFS RPMs for AMD64
systems :)


Thanks,

Chris Wing
wingc@engin.umich.edu