[39025] in Kerberos
Re: KRB5 ccache on MACOS
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Mon Oct 11 09:07:47 2021
Message-ID: <202110111304.19BD4x9j002024@hedwig.cmf.nrl.navy.mil>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: "Markus Moeller" <huaraz@moeller.plus.com>
In-Reply-To: <sjvt6r$37g$1@ciao.gmane.io>
MIME-Version: 1.0
Date: Mon, 11 Oct 2021 09:04:59 -0400
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>It is
>
>#sw_vers
>ProductName: macOS
>ProductVersion: 11.6
>BuildVersion: 20G165
Alright, so, Big Sur.
There were significant changes in the credential cache support on Big Sur.
I didn't check for file cache support, but .... it looks like to me that
in fact Kerberos on Big Sur _does_ respect the KRB5CCNAME enviroment
variable:
% env KRB5CCNAME=FILE:/tmp/foo klist
Credentials cache: FILE:/tmp/foo
Principal: kenh@CMF.NRL.NAVY.MIL
[...]
Now it may be that gss_init_sec_context() may be doing something slightly
more magical. If that is the case ... well, I'm not sure there is an
easy fix for that.
You can share API credential caches; previously to Big Sur it used Mach Ports
for the IPC mechanism, and that was based on the Unix userid for access.
With the new mechanism, I am not sure how that works, exactly. Specifically
I do not know whether or not you can access one set of credentials from
another login session.
Regarding your problem with MIT Kerberos, I think your problem THERE is
that MIT Kerberos does not support the new credential cache mechanism on
Big Sur, and basically that error you are getting means "No credentials
found". I submitted a pullup request to add support for that, and it
is here:
https://github.com/krb5/krb5/pull/1221
If you apply that patch to MIT Kerberos, it might work better for you.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
