Great, thanks!
Valerie
On 1/4/2018 4:51 AM, Jan Kalina wrote:
Described issues was accepted into Oracle JDK issues:
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
(fixing patches are included in reports too)
On Fri, Dec 22, 2017 at 5:44 PM, Jan Kalina <jkal...@redhat.com
<mailto:jkal...@redhat.com>> wrote:
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
This can be reproduced by recreating GSSManager before
createGSSContext - ProviderList.factories
will be initialized as part of initSecContext/acceptSecContext
which will cause using wrong initialized
SunNativeProvider.INSTANCE and described exception.
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.
Thanks,
Jan
On Wed, Dec 20, 2017 at 1:42 AM, Valerie Peng
<valerie.p...@oracle.com <mailto:valerie.p...@oracle.com>> wrote:
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
