First instance is created on initialization of SunNativeProvider.INSTANCE, but it is BEFORE
When I has try to debug it, I has found the SunNativeProvider is created in two instances:
But when I try to use it, it claims mechanism with given OID are not supported:
I has found bug in SunNativeProvider:When debug messages are enabled, JDK confirms GSS library was loaded with mechs:
SunNativeGSS: Loaded GSS library: /usr/lib64/libgssapi_krb5.so.2.2
SunNativeGSS: Native MF for 1.2.840.1135126.96.36.199
SunNativeGSS: Native MF for 188.8.131.52.5.2.5
SunNativeGSS: Native MF for 184.108.40.206.5.5.2
GSSException: Provider SunNativeGSS does not support mechanism 1.2.840.1135220.127.116.11
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?
Attaching patch, which fixes described issue for me.
On Thu, Dec 14, 2017 at 4:03 PM, Jan Kalina <[hidden email]> wrote:
jdk-patch-native.patch (1K) Download Attachment
I will take a look. Do you happen to have a test case that I can
reproduce the issue?
On 12/14/2017 9:20 AM, Jan Kalina wrote:
SunNativeProvider.INSTANCE and described exception.
This can be reproduced by recreating GSSManager before createGSSContext - ProviderList.factories
Hi, I was just able to prepare usable reproducer (attaching in ZIP file) and fixing patch of JDK (attaching too).
Before I was able to make my usecase working, I has found second issue too - I has included it too.
Issues and their reproducing:
1) already described problem of wrong initialized SunNativeProvider.INSTANCE
will be initialized as part of initSecContext/acceptSecContext which will cause using wrong initialized
2) when channel binding is used SIGSEGV occure
This can be reproduced by setting channel binding without initAddr/acceptAddr.This is caused by sending uninitialized (with random length) cb->initiator_address from JDK to the kerberos.
(It is used by krb library for messages checksum calculation even when addrtype is GSS_C_AF_NULLADDR.)
Attached reproducer-gss.zip reproduces both issues and attached patch fixes both.
I would welcome merging into OpenJDK. (I am covered by OCA of Red Hat)
This issue affect both tested JDKs, JKD8u121 and upstream JDK9 from mercurial master.
On Wed, Dec 20, 2017 at 1:42 AM, Valerie Peng <[hidden email]> wrote:
Described issues was accepted into Oracle JDK issues:(fixing patches are included in reports too)
1) SunNativeProvider.INSTANCE initialization: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194073
2) Uninitialized cb->initiator_address: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194630
On Fri, Dec 22, 2017 at 5:44 PM, Jan Kalina <[hidden email]> wrote:
On 1/4/2018 4:51 AM, Jan Kalina wrote:
|Free forum by Nabble||Edit this page|