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

Sean O'Malley omalleys@msu.edu
Thu, 20 May 2004 12:56:11 -0400 (EDT)


This seemed to build okay on fedora core 1 32-bit intel. I haven't tested
it yet.

Except afs2k5db.c

In file included from afs2k5db.c:35:
/root/krb5-1.3.3/src/include/k5-int.h:1816: error: syntax error before
"krb5_donot_replay"

If you edit k5-int.h:1816 and just remove the
,krb5_donot_replay *
it seems to build although it may have an adverse effect. =)

There were various warning about incompatible pointer types and
redefinitions throughout the build which always make me leary.

But thanks! that is the first time I tried to build that package and it
didn't choke in a 100 different places.


--------------------------------------
  Sean O'Malley, Information Technologist
  Michigan State University
-------------------------------------

On Mon, 17 May 2004, Christopher Allen Wing wrote:

> 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
>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>