Mac OS X Kerberos SCDynamicStore
Landon Fuller
landonf at plausible.coop
Thu Mar 14 20:40:35 PDT 2013
On Mar 14, 2013, at 10:41 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> On 3/15/13 10:06 AM, Landon Fuller wrote:
>> 1) No longer falls back to krb5.conf
>
> This has been fixed in http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c69b4d9ace.
Woot. Sorry I missed the later rev.
>> 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.
I suppose I might qualify. Most of the usages of NSLog() there will only be triggered in unexpected circumstances, eg, the events they log should never occur outside of some sort of system failure in the SystemConfiguration framework.
There are two cases where returning NULL are expected behavior (eg, not an error, there's just no registered configuration) and I don't think warrant logging in the native code:
diff -r d79503c4c56f src/macosx/native/java/util/SCDynamicStoreConfig.m
--- a/src/macosx/native/java/util/SCDynamicStoreConfig.m Thu Mar 14 11:29:16 2013 -0700
+++ b/src/macosx/native/java/util/SCDynamicStoreConfig.m Thu Mar 14 23:08:44 2013 -0400
@@ -183,7 +183,6 @@
CFTypeRef realms = SCDynamicStoreCopyValue(store, (CFStringRef) KERBEROS_DEFAULT_REALMS);
if (realms == NULL || CFGetTypeID(realms) != CFArrayGetTypeID()) {
- NSLog(@"Unable to load realm info from SCDynamicStore");
if (realms) CFRelease(realms);
CFRelease(store);
return NULL;
@@ -192,7 +191,6 @@
CFTypeRef realmMappings = SCDynamicStoreCopyValue(store, (CFStringRef) KERBEROS_DEFAULT_REALM_MAPPINGS);
if (realmMappings == NULL || CFGetTypeID(realmMappings) != CFArrayGetTypeID()) {
- NSLog(@"Unable to load realm mapping info from SCDynamicStore");
if (realmMappings) CFRelease(realmMappings);
CFRelease(realms);
CFRelease(store);
The Java side could still check something like 'sun.security.krb5.debug' and log an error if SCDynamicStoreConfig.getKerberosConfig() returns NULL, I suppose?
> BTW, I'm also making changes to SCDynamicStoreConfig.m
>
> http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006909.html
For whatever it's worth -- adding a coercions for NSData and NSDate would cover the full gamut of the possible return types from SCDynamicStoreCopyValue(). All but dates and data are covered by your registered coercers (the returned CFPropertyListRef represents types of CFData, CFString, CFArray, CFDictionary, CFDate, CFBoolean, and/or CFNumber, with CFBoolean being a specialization/subclass of CFNumber).
-landonf
More information about the macosx-port-dev
mailing list