On Tue, Jul 28, 2009 at 03:48:47PM +0800, Weijun Wang wrote:
> #include <krb5.h> // always the MIT one
>
> /* Used to reference fields before keyblock */
> krb5_creds * pcreds;
> /* Used to reference fields after keyblock */
> krb5_creds * pcreds2;
>
> pcreds = (krb5_creds *)malloc(sizeof(krb5_creds)+12);
> while (!(code = CALL(krb5_cc_next_cred)(kcontext, cache, &cur, pcreds)))
> {
> #ifdef __SUNPRO_C
^^^^^^^^^^
It's not the compiler that tells you whether you're on Solaris 10...
> if (pcreds->ticket.magic == KV5M_DATA) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Neither MIT nor Solaris libkrb5 are very good at ensuring that the magic
fields are set right every time, and often don't check them either.
One resync backported into an S10 update and this check will break. See
my other e-mail about using symbols for your heuristic (and the fact
that any heuristic you pick is going to be less than very robust).
> pcreds2 = pcreds;
> } else {
> /* Looks like the Solaris version,
> keyblock has extra 12 bytes */
> pcreds2 = (krb5_creds *)((char*)pcreds + 12);
> if (pcreds2->ticket.magic != KV5M_DATA) {
> goto Bad; /* What? Not repaired? */
> }
> }
> #else
> pcreds2 = pcreds;
> #endif
> }
Clever, indeed. I'd rather that you find a better alternative. But
first we need to hear your goals and requirements -- right now I'm only
guessing. Earlier you mentioned that you wanted to use the krb5_cc_*
APIs to get at CCAPI ccaches when we add that feature. Since Java
supports FILE ccaches and S10 is unlikely to ever have CCAPI ccaches,
why bother trying to use libkrb5 from Java Kerberos on S10? I thought
the issue was Nevada/OpenSolaris. But perhaps there's more to this
project than I guessed.
Nico
--
