Mac OS X Kerberos SCDynamicStore

[Weijun Wang]

On 3/15/13 10:06 AM, Landon Fuller wrote:
> Howdy,
>
> I've been working a bit with Kerberos on Mac OS X, and ran into an issue with krb5.conf handling. Back in 2011, changeset 0785fa5940f6 introduced some changes to how the system kerberos configuration is handled on Mac OS X:
> 	http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/0785fa5940f6
>
> There were a few issues with this changeset, which I'll address in order:
>
> 1) No longer falls back to krb5.conf

This has been fixed in 
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c69b4d9ace.

>
> On modern Mac OS X, the various kerberos libraries consult the dynamic configuration from SCDynamicStore, and fall back on parsing the krb5.conf. As far as I'm aware, if you're not using Apple's OpenDirectory, or Microsoft ActiveDirectory, krb5.conf is the only supported way to configure system-wide kerberos behavior -- the SCDynamicStore's contents are undocumented AFAIK and effectively opaque:
>
> In the revision referenced above, the krb5.conf fallback handling was disabled on Mac OS X Lion and later releases, and instead *only* the SCDynamicStore is used:
>
>        731                 } else if (osname.startsWith("Mac")) {
>        732                     if (isLionOrBetter()) return "";
>        733                     name = findMacosConfigFile();
>        734                 }
>
> It would seem that this should be modified to re-instate the krb5.conf parsing in the case that SCDynamicStore fails to return a default realm.
>
> 2) Spurious output to stderr

This was filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7151062.

I was waiting for someone familiar with Objective-C to do this, but 
maybe we can just remove those NSLog calls.

>
> Additionally, the SCDynamicStoreConfig.m implementation actually prints out an error message to stderr in the case where it cannot find a default domain. Since this is actually non-error behavior, this printing seems extraneous. This seems to have been raised previously be Weijun Wang:
> 	http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003490.html
>
> ... and seems to have impacted some third-party software:
> 	https://www.google.com/search?q="Unable+to+load+realm+info+from+SCDynamicStore"
>
> 3) Use of SPI

Oh.

>
> I hesitated to include this last one, but ultimately I figured it's at least worth bringing up. As far as I know -- and from what I've confirmed with contacts at Apple -- the specific contents of the SCDynamicStore (including the 'Kerberos-Default-Realms' keys et al used by the Java code contributed by Apple) are considered SPI. The corresponding Heimdal headers from Apple states:
> 	"SPI constants for OD/Heimdal communication for default realm and location data using SystemConfiguration. This is a private interface and can change any time."
> 	http://www.opensource.apple.com/source/Heimdal/Heimdal-172.18/lib/krb5/HeimdalSystemConfiguration.h
>
> I don't know what the project norms are for this sort of thing, and I can't see any other way to accomplish this, so I figured I'd just mention it. The public kerberos APIs do provide access to the default realm name, but they don't (as far as I can see -- perhaps someone else will know better) provide access to the other [libdefaults] configuration values that are required.
>
> 4) Conclusion
>
> If you've made it this far, congratulations. I don't know if anyone is specifically responsible for the area in question, or if anyone has direction on an appropriate resolution. I can fairly easily resolve #1 and #2, and submit a patch.

I'm maintaining kerberos.

>
> Coming from the BSD port, I also don't actually know if I have commit privileges on the Mac OS X port and wouldn't know proper procedures if I did :) Currently I'm listed as an 'author':
> 	http://openjdk.java.net/census#landonf

The macosx-port repositories are not active now, so you should directly 
push into other repos (say, jdk/tl). I'll see how to promote you to a 
comitter.

BTW, I'm also making changes to SCDynamicStoreConfig.m

 
http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006909.html

Thanks
Max

>
> Thanks,
> Landon
>