>* MacPorts MIT Kerberos `kdestroy -A` >* MacPorts MIT Kerberos `kinit -F [email protected]` -- works >* MacPorts MIT Kerberos `kinit -F akkornel/[email protected]` -- works! >* MacPorts MIT Kerberos `klist -l` -- lists two credential caches!
Ok, great! So that explains that. I couldn't actually reproduce that myself, but maybe it requires a reboot. I'll see if testing that inside of a clean VM makes a difference. The difference here is (as you note in the rest of your email) that all of the other calls to the function cc_context_create_new_ccache() have a principal name. I am guessing that using "" works fine when you have a default realm set, but doesn't if you don't. I dug into this further, as the Heimdal and MIT APIs are MOSTLY the same; this all stems from the call to krb5_cc_gen_new() which does NOT take a principal name. All of the Heimdal/MacOS calls to the ccapi functions do the same thing: their implementation of cc_gen_new() just initializes an internal structure, but the call to create the new credential cache is deferred until the call to krb5_cc_initialze() which DOES take a principal name. So this is a MIT Kerberos bug, and it seems like the two solutions are: 1) use a dummy principal name in the cc_gen_new() function, or 2) defer credential cache creation until cc_initialize() is called. Let me think about the best answer, but either way I'll code up a fix and submit it to MIT so it should get fixed upstream eventually. --Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
