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 akkor...@stanford.edu` -- works
* `~/bin/krb5/bin/kinit -F akkornel/r...@stanford.edu` -- 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 akkor...@stanford.edu` -- works
* `~/bin/krb5/bin/kinit -F akkornel/r...@stanford.edu` -- 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/r...@stanford.edu
… 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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
