I will take a look. Do you happen to have a test case that I can
reproduce the issue?
Thanks,
Valerie
On 12/14/2017 9:20 AM, Jan Kalina wrote:
Attaching patch, which fixes described issue for me.
On Thu, Dec 14, 2017 at 4:03 PM, Jan Kalina <jkal...@redhat.com
<mailto:jkal...@redhat.com>> wrote:
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
