[39478] in Kerberos
Re: macOS API ccache, kinit for multiple principals gives internal
daemon@ATHENA.MIT.EDU (A. Karl Kornel)
Mon Feb 17 18:19:51 2025
MIME-Version: 1.0
Date: Mon, 17 Feb 2025 15:18:09 -0800
From: "A. Karl Kornel" <karl@kornel.us>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: kerberos@mit.edu
In-Reply-To: <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil>
Message-ID: <5088ed0bca390db875d6322977d681c6@kornel.us>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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 akkornel@stanford.edu` -- works
* `~/bin/krb5/bin/kinit -F akkornel/root@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 akkornel@stanford.edu` -- works
* `~/bin/krb5/bin/kinit -F akkornel/root@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/root@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
