[20263] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: Big Sur & MIT Kerberos no longer interoperate

daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Mar 20 02:13:55 2021

To: Ken Hornstein <kenh@cmf.nrl.navy.mil>, <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <43d52b48-9445-72bd-a915-2716d6b730bf@mit.edu>
Date: Sat, 20 Mar 2021 02:13:43 -0400
MIME-Version: 1.0
In-Reply-To: <202103192359.12JNxq2p017773@hedwig.cmf.nrl.navy.mil>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

On 3/19/21 8:02 PM, Ken Hornstein wrote:
> So we have noticed in our testing that SOMETHING has changed on Big Sur,
> and MIT Kerberos and the vendor MacOS X Kerberos no longer interoperate.
> Specifically, MIT Kerberos and Big Sur Kerberos cannot see each other's
> credential caches; a "kinit" with one implementation has credential
> caches that are not visible from the other.

>From a look at the latest forked Heimdal code on opensource.apple.com,
Apple seems to have switched the default ccache type to a new type
called XCC, which is built on top of a macOS IPC framework called XPC.

It looks like it would require a fair amount of code for us to
interoperate with the XCC cache, and unlike the KCM code, it wouldn't
give us ancillary benefits on other platforms.  So I'm not certain what
we'll do.  One option is to create a public ccache pluggable interface
to allow maintenance of an XCC plugin module outside of our tree, but
that (1) assumes someone would put in that work, and (2) would be harder
to deploy than just building MIT krb5 and having it use the native
ccache automatically.
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post