[39477] in Kerberos
Re: macOS API ccache,
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Wed Feb 12 19:22:01 2025
Message-Id: <202502130017.51D0Hgug009261@hedwig.cmf.nrl.navy.mil>
To: "A. Karl Kornel" <karl@kornel.us>
cc: kerberos@mit.edu
In-Reply-To: <454ad95255b0e02a0ad42e2f2687740e@kornel.us>
MIME-Version: 1.0
Date: Wed, 12 Feb 2025 19:17:42 -0500
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
