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

On 2025-02-12 04:17 PM, Ken Hornstein wrote:

> <<<snip>>>
> 
> 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.

That's entirely possible, and I should've tried to reproduce this on a 
stock krb5 build first.  So, I just did that.

I also switched to a macOS 15.3 system, which I'll be using from now on.

To confirm, the steps I followed to build krb5:

* Cloned from https://github.com/krb5/krb5.git
* Checked out tag 'krb5-1.21.3-final'
* `mkdir ~/bin/krb5`
* `cd src && autoreconf`
* `./configure --prefix "$HOME/bin/krb5" --enable-dns-for-realm 
--disable-pkinit && make && make install`

With the build complete, I did the following tests:

* `~/bin/krb5/bin/kdestroy -A`
* `~/bin/krb5/bin/kinit -F [email protected]` -- works
* `~/bin/krb5/bin/kinit -F akkornel/[email protected]` -- fails
* `~/bin/krb5/bin/klist -l` -- lists one ccache, for akkornel at 
stanford.edu

So, still failing, unfortunately.

> 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().

I've never use LLDB before, but I decided to give it a try.  On my first 
try, I got a warning about `kinit` being optimized.  So, I erased 
"~/bin/krb5", set environment variable CFLAGS="-O0 -g", and re-ran the 
`./configure … && make && make install`.

With the newly-installed non-optimized krb5, I reran my tests and got 
the same results:

* `~/bin/krb5/bin/kdestroy -A`
* `~/bin/krb5/bin/kinit -F [email protected]` -- works
* `~/bin/krb5/bin/kinit -F akkornel/[email protected]` -- fails
* `~/bin/krb5/bin/klist -l` -- lists one ccache, for akkornel at 
stanford.edu

So, debug time!  I used…

lldb -- ~/bin/krb5/bin/kinit -F akkornel/[email protected]

… to start LLDB.  Then …

breakpoint set --name api_macos_gen_new

… to set the breakpoint.  I ran until it hit the breakpoint, then 
started stepping through.

* cc_initialize returned returned 0, so not that.

* cc_context_create_new_ccache returned 2529639136.  There we go.

It took me some work, but I eventually realized that 
cc_context_create_new_ccache wasn't an actual function, and was 
resolving to the Kerberos Framework's context_create_new_ccache.

I'm not sure how to debug macOS Frameworks.  I tried single-stepping 
through assembly, and I noticed execution was making it through the 
Kerberos Framework and into the Heimdal Framework.  And then back into 
MIT Kerberos code‽  I think the first parameter is a struct with a ton 
of pointers, and that's being passed around.

I'll continue exploring.  I'm also considering setting up a macOS VM—via 
UTM—to see if this also happens on a completely-clean system.

~ Karl
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos