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

[Ken Hornstein]

>I have run into an issue with krb5 1.21.1 on macOS 14+, related to the 
>new API ccache type: If I already have a credential cache, doing a 
>`kinit` for a different principal will return "Internal credentials 
>cache error while generating new ccache".  However, using macOS 
>Kerberos' `kinit` works fine.  I thought to report it here, in case it 
>is fixable.

I cannot reproduce this.  I was able to use MIT Kerberos to kdestroy -A,
kinit to two different principals, and it worked fine.

However, some caveats.

- We are using our own MIT build with a few custom patches.  Nothing that
  affected the Apple credential cache support (which I contributed to MIT
  Kerberos so I know how it works).  It is based on 1.21.3.

- HOWEVER ... I just did a test build of stock MIT Kerberos 1.21.3 and
  repeated the same steps: works fine.  On a long shot I thought that
  maybe the -F option affected things, so I tried again using that;
  still worked fine.

- I tested on Sequoia (MacOS 15), not Sonoma.  I developed this support
  before Sonoma so I have a hard time believing that it is broken on
  Sonoma, but I could be wrong.

- I tested principals in two different realms.  I don't think this should
  affect anything, but I just wanted to state it for completeness.

As a note, it has been my experience that MacPorts can create a dependency
hell where package behavior can depend on what you have installed when you
go to build a package.  For this reason (and others) I exclusively recommend
Homebrew to people instead of MacPorts.

The way that the MacOS X credential cache support works is that it
explicitly links in the MacOS X Kerberos framework when building MIT
Kerberos via the '-framework Kerberos' command-line option and then
makes calls to the ccapi functions to do the appropriate things.  From
my memory, Heimdal took a slightly different approach and decided to
dlopen that framework library instead and then do the ccapi calls.

My gut feeling is that this is a MacPorts problem, but I am open to
being proven wrong.  I think, however, you're going to have to debug
this yourself further; this looks like it is failing inside of
api_macos_gen_new(), and is probably failing in either cc_initialize(),
cc_context_create_new_ccache(), or cc_ccache_get_name().

--Ken