答复: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout asmsec instead of sec
Weijun Wang
weijun.wang at oracle.com
Wed May 14 12:14:18 UTC 2014
On 5/14/2014 19:51, christos at zoulas.com wrote:
> On May 14, 2:04pm, weijun.wang at oracle.com (Weijun Wang) wrote:
> -- Subject: =?utf-8?Q?=E7=AD=94=E5=A4=8D:_RFR_8036779:_sun.security.krb5.KdcC
>
> | What do you mean by detecting the platform? So if I find the file is also u=
> | sed by NetBSD krb5 then I treat it as second and if not millisecond? That's=
> | quite impossible. In my opinion, it all depends on how the writer is educa=
> | ted, Java or some else.
> |
> | How is this unsafe, especially compared to if we don't fix it? The only bad=
> | thing is that if someone wants to set the timeout to be less than 120 ms, =
> | now there will be no way to do it. But that should never happen, right?
> |
> | My comment in the bug mentions we can support "5s", but then I realize it d=
> | ies not really solve the unit-less case.
>
> There were three major implementations of Kerberos before Java. Two of them
> (MIT and Heimdal) used krb5.conf (the third being Microsoft). Both treat naked
> time values as seconds. Heimdal just documented better what MIT did, since it
> was built with compatibility to the MIT reference implementation in mind:
>
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man5/krb5.conf.5.html
> http://web.mit.edu/kerberos/krb5-devel/doc/basic/date_format.html#duration
>
> Since java is re-using an existing file with an existing format it should
> be parsing the values using the same default units. Otherwise it should stop
> using that file.
This is correct, but unfortunately Java has parsed that value in a wrong
way for a very long time and has its own compatibility concern now.
That's why I suggest the (value < 120 ? sec : msec) rule. Do you think
it works?
>
> What's even weirder is if java behaves differently depending if I am using
> the native OS kerberos libraries instead of the java ones.
I don't want to be so smart either.
Thanks
Max
>
> christos
>
More information about the security-dev
mailing list