Bug in SunNativeProvider

Jan Kalina jkalina at redhat.com
Thu Dec 14 15:03:02 UTC 2017


I has found bug in SunNativeProvider:

When debug messages are enabled, JDK confirms GSS library was loaded with
mechs:

[GSSLibStub_init] libName=/usr/lib64/libgssapi_krb5.so.2.2
SunNativeGSS: Loaded GSS library: /usr/lib64/libgssapi_krb5.so.2.2
SunNativeGSS: Native MF for 1.2.840.113554.1.2.2
SunNativeGSS: Native MF for 1.3.6.1.5.2.5
SunNativeGSS: Native MF for 1.3.6.1.5.5.2

But when I try to use it, it claims mechanism with given OID are not
supported:

GSSException: Provider SunNativeGSS does not support mechanism
1.2.840.113554.1.2.2
    at
java.security.jgss/sun.security.jgss.ProviderList.getMechFactory(ProviderList.java:253)
    at
java.security.jgss/sun.security.jgss.ProviderList.getMechFactory(ProviderList.java:209)
    at
java.security.jgss/sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:234)
    at
java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:337)
    at
java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:302)

*When I has try to debug it, I has found the SunNativeProvider is created
in two instances:*

First instance is created on initialization of SunNativeProvider.INSTANCE,
but it is BEFORE
the mechs are passed into SunNativeProvider.MECH_MAP. The second instance
is created
correctly in ProviderList constructor.

The problem is, in some situations is used the too soon created
SunNativeProvider.INSTANCE,
so the to call throws exception above.

*I think sufficient fix would be to move SunNativeProvider.INSTANCE
declaration after*
*the static constructor (filling the **MECH_MAP) in SunNativeProvider file.*

Would be possible to fix this?
Should I send a patch?

Thanks
Jan Kalina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20171214/10ebb694/attachment.htm>


More information about the security-dev mailing list