Bug ID: JDK-8036779 sun.security.krb5.KdcComm interprets kdc

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 8	JDK 9	Other
8u20Fixed	9 b16Fixed	openjdk7uFixed

FULL PRODUCT VERSION :
jdk1.7.0_51.jdk
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)



ADDITIONAL OS VERSION INFORMATION :
OS X 10.9.2 Build 13C64
Darwin i7.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64

A DESCRIPTION OF THE PROBLEM :
sun.security.krb5.KdcComm uses kdc_timeout value using Config, and interprets its value as millisecond, which causes really fast fails. It really should be considered as second.

 http://www.daemon-systems.org/man/krb5.conf.5.html
[libdefaults]
kdc_timeout = time
Maximum time to wait for a reply from the kdc,
default is 3 seconds.

REGRESSION.  Last worked in version 6u45


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
System.setProperty("java.security.krb5.conf", "/dev/null");

The affected testcases could pass in nightly result: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=669066.CORELIBS-JDK-NIGHTLY-JTREG-17, verified it.
26-12-2014
suggested release-note: An interop issue is found between Java and the native Kerberos implementation on BSD (including Apple OS X) on the kdc_timeout setting in krb5.conf, where Java interprets as milliseconds and BSD as seconds (when no unit is specified). JDK-8036779 adds support for the "s" (second) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerning on interop between Java and BSD should use the later format.
29-05-2014
Discussion being captured on OpenJDK mail thread : http://mail.openjdk.java.net/pipermail/security-dev/2014-May/010482.html
15-05-2014
Just noticed this is Mac OS X. Maybe the Apple JDK treats kdc_timeout as seconds? This is possible. Can anyone out there test for this?
13-05-2014
We've always treated kdc_timeout as msec so this is not a regression. But it does look like our definition is not the same as the linked doc. Said that, the time value there is defined as "values can be a list of year, month, day, hour, min, second. Example: 1 month 2 days 30 min. If no unit is given, seconds is assumed." It looks like we can at least support the format with units. This way we can ask the customer to specify the unit explicitly for interop. Whether we can complete change the "milliseconds is assumed" behavior to "seconds is assumed" is debatable, but possibly doable. I would consider a bare number bigger than 1000 as milliseconds and smaller ones as seconds. It seems quite safe since I cannot imagine someone sets a 1000 seconds timeout.
13-05-2014
I think the submitter's problem is that if value is set to '3' - the JDK interprets it as 3ms. Docs are misleading. Has kdc_timeout always been specified in ms for krb5 implementations ?
13-05-2014
default is 30 seconds not 3 seconds as listed in the bug report if the value is specified, it is treated as milliseconds
13-05-2014
Max - could this be assigned to you ? I think there might be an issue here. The man page suggests seconds is to be used where as the code parses it as milliseconds.
13-05-2014