macOS API ccache, kinit for multiple principals gives internal credentials cache error

[Ken Hornstein]

>* MacPorts MIT Kerberos `kdestroy -A`
>* MacPorts MIT Kerberos `kinit -F akkornel at stanford.edu` -- works
>* MacPorts MIT Kerberos `kinit -F akkornel/root at stanford.edu` -- 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