Bug 457522 - mojebanka.cz (e-banking) does not work with openjdk
mojebanka.cz (e-banking) does not work with openjdk
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Deepak Bhole
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-01 06:39 EDT by Martin Sourada
Modified: 2009-03-04 18:32 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-04 16:16:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Terminal output from the login page (52.57 KB, text/plain)
2008-08-01 06:39 EDT, Martin Sourada
no flags Details
Terminal output from the Configuration Wizard page (21.00 KB, text/plain)
2008-08-01 06:41 EDT, Martin Sourada
no flags Details
Screenshot of applet from www.mojebanka.cz loaded (109.60 KB, image/jpeg)
2009-02-25 17:04 EST, Deepak Bhole
no flags Details

  None (edit)
Description Martin Sourada 2008-08-01 06:39:59 EDT
Description of problem:
mojebanka.cz fails to detect installed openjdk plugin. I'll attach output in
terminal when attempting to load it.

Version-Release number of selected component (if applicable):
java-1.6.0-openjdk-plugin-1.6.0.0-0.16.b09.fc9.i386

How reproducible:
always

Steps to Reproduce:
1. Go to https://www.mojebanka.cz/InternetBanking/JSPLogin.jsp?L=EN
2. Wait for applet inicialization
  
Actual results:
Window pops up saying that java is not installed/enabled. Hitting OK forwards to
Configuration Wizard which fails to detect the java as well.

Expected results:
Applet is succesfully loaded.

Additional info:
Works with Sun Java.
Comment 1 Martin Sourada 2008-08-01 06:39:59 EDT
Created attachment 313183 [details]
Terminal output from the login page
Comment 2 Martin Sourada 2008-08-01 06:41:23 EDT
Created attachment 313184 [details]
Terminal output from the  Configuration Wizard page
Comment 3 Lubomir Rintel 2008-08-01 11:11:38 EDT
Heh, I thought this was a feature to protect me from spending money unnecessarily.
Comment 4 Lillian Angel 2008-08-12 12:49:47 EDT

*** This bug has been marked as a duplicate of bug 304021 ***
Comment 5 Deepak Bhole 2008-10-22 17:33:40 EDT
Looks like this may never work on 64-bit :( The applet downloads a .so file and loads it via JNI. The .so is 32-bit only, and throws errors like this:

java.lang.UnsatisfiedLinkError: /tmp/kbpki/lib101fc9c41bc42486fa9f.so: /tmp/kbpki/lib101fc9c41bc42486fa9f.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
Comment 6 Jan Kratochvil 2009-02-20 18:57:08 EST
Bug 304021 (JavaScript linkage) was not the only reason.

Another problem is mojebanka.cz ignores 64bit arches and supplies just 32bit .so.

nspluginwrapper cannot be used for 32bit libjavaplugin.so:
nspluginwrapper: /usr/lib/mozilla/plugins/libjavaplugin.so is not a valid NPAPI plugin
according to the web the Java plugin is a different plugin type which is unsupported by nspluginwrapper.

Another problem appears to be with SELinux even in Permissive mode.
kernel: type=1400 audit(1235172365.819:15): avc:  denied  { execmod } for  pid=10038 comm="java" path="/tmp/kbpki/libae663b1e382548b247b2.so" dev=dm-0 ino=516170 scontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file

With SELinux Disabled and running firefox.i386 it started with java-1.6.0-openjdk-plugin-1.6.0.0-9.b14.fc10.i386.  Just it does not work on the next attempts:

Window manager warning: Invalid WM_TRANSIENT_FOR window 0xa00007 specified for 0xa0001b (Warning - ).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0xa00016 specified for 0xa0001b (Warning - ).
[DEBUG]   [IBSignerApplet] init() -> entered the privileged block.
[DEBUG]   IBSignerApplet INIT 
LLoggerFactory: java.lang.ClassNotFoundException: org/apache/log4j/Logger
Re-loading a properties for 'US'.
Property "java.vendor" = Sun Microsystems Inc.
Property "java.version" = 1.6.0_0
[PKIApplet.init()] PKIApplet ibapp:1.5.2.0|shapp:6.0.0.7|ktpsp:5.2.2.7. Copyright LogicaCMG 2005.
[PKIApplet.init()] CLASS PATH: .
[PKIApplet.init()] JAVA HOME: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre
[PKIApplet.init()] USER HOME: /root
[PKIApplet.init()] JAVA VENDOR: Sun Microsystems Inc.
[DEBUG]   verifying codebase
[DEBUG]   codebase approved
[DEBUG]   docbase approved
[PKIAppletConfig] Config file 'PKIApplet.properties' loaded.
localeParam = CZ
Re-loading a properties for 'CZ'.
Creating new IDllVerifier instance
Creating instance of com.logica.security.devicemgr.dllverifier.HashAndSizeDllVerifierImpl
(Re)Setting DLLs for verification (global flag reset):
  lcpkcs11
  CAPI2_JNI
  mopkcs11.dll
    removed suffix:mopkcs11.dll
Processing DLL:lcpkcs11
Can't create absolute file. Skipping name: lcpkcs11
Processing DLL:CAPI2_JNI
Can't create absolute file. Skipping name: CAPI2_JNI
Processing DLL:mopkcs11
Can't create absolute file. Skipping name: mopkcs11
asking server for verification status
verification URL:https://www.mojebanka.cz/confwiz/confirmLibHash?q=
received from server:UNTRUSTED
libraries considered as UNtrusted by the server
Detected JRE 16, provider put on the 1st place.
JCRYPTO Security Provider added.
java.lang.NullPointerException
	at com.logica.apps.ivs.client.applet.PKIAppletRaw.init_Raw(Unknown Source)
	at cz.kb.pki.client.applet.PKIAppletRawKB.init_Raw(PKIAppletRawKB.java:52)
	at kbib.security.signer.IBSignerAppletRaw.init_Raw(IBSignerAppletRaw.java:131)
	at kbib.security.signer.IBSignerApplet$1.run(IBSignerApplet.java:31)
	at java.security.AccessController.doPrivileged(Native Method)
	at kbib.security.signer.IBSignerApplet.init(IBSignerApplet.java:26)
	at sun.applet.AppletPanel.run(AppletPanel.java:436)
	at java.lang.Thread.run(Thread.java:636)
[PARAMETER] LOADCAPI parameter is missing. Default is: false
Cleaning the DLL's in the temp dir.
NOT loading CAPI2_JNI.dll, switched off in the configuration.
Dll load failed: liblcpkcs11.so
com.logica.security.devicemgr.dllloader.DllLoaderException: Could not find liblcpkcs11.so in the system. Loading stopped.
	at com.logica.security.devicemgr.dllloader.DefaultDllLoader.getDllStream(DefaultDllLoader.java:43)
	at com.logica.security.devicemgr.dllloader.DllLoader.loadDll(DllLoader.java:133)
	at com.logica.apps.ivs.client.applet.PKIAppletRaw.init_Raw(Unknown Source)
	at cz.kb.pki.client.applet.PKIAppletRawKB.init_Raw(PKIAppletRawKB.java:52)
	at kbib.security.signer.IBSignerAppletRaw.init_Raw(IBSignerAppletRaw.java:131)
	at kbib.security.signer.IBSignerApplet$1.run(IBSignerApplet.java:31)
	at java.security.AccessController.doPrivileged(Native Method)
	at kbib.security.signer.IBSignerApplet.init(IBSignerApplet.java:26)
	at sun.applet.AppletPanel.run(AppletPanel.java:436)
	at java.lang.Thread.run(Thread.java:636)
WARNING - Failed to initialize the liblcpkcs11.so library.
bTestDevInst = true
testDeviceInstalled_Raw() - started
WARNING - Knihovna ovladače čipové karty nebyla nalezena - mopkcs11.dll.
bIsDeviceInstalled = false
[DEBUG]   Temporary directory: /tmp/kbpki
[DEBUG]   Final dir: /root/kbpki/nativLib
Cleaning the DLL's in the temp dir.
File /tmp/kbpki/libeec8667bf82673029a3f.so successfully deleted.
PathDllLoader: Found resource for CIMNativeLib in specified path.
getCopiedDLLName -> completeFile = /tmp/kbpki/libf80585638bdb9c9d6831.so
Loading the COPIED CIMNativeLib library, file name: /tmp/kbpki/libf80585638bdb9c9d6831.so
    absolute file detected, suffix wont be removed:/tmp/kbpki/libf80585638bdb9c9d6831.so
Processing DLL:/tmp/kbpki/libf80585638bdb9c9d6831.so
template DllVerificationInfo created:LIBF80585638BDB9C9D6831.SO|80752|82DFEBC630A1A702D547C91D7887AC399DE2DD63
asking server for verification status
verification URL:https://www.mojebanka.cz/confwiz/confirmLibHash?q=LIBCIMNATIVELIB.SO|80752|82DFEBC630A1A702D547C91D7887AC399DE2DD63|
received from server:TRUSTED
libraries considered as trusted by the server
same hash and different filenames - verification continues - LIBCIMNATIVELIB.SO|80752|82DFEBC630A1A702D547C91D7887AC399DE2DD63 vs. LIBF80585638BDB9C9D6831.SO|80752|82DFEBC630A1A702D547C91D7887AC399DE2DD63
match found - library approved for : /tmp/kbpki/libf80585638bdb9c9d6831.so; full path flag: true
The COPIED CIMNativeLib library successfully loaded.
CIMNativeLib version: n/a. Versioning not supported. libCAPI2_JNI.so not loaded.
[DEBUG]   CIMNativeLib library successfully loaded - version: 1.0.0.0.
Comment 7 Deepak Bhole 2009-02-24 15:30:12 EST
IcedTeaPlugin uses OJI, so it will not work with nspluginwrapper, unfortunately.

As for the SELinux errors -- in permissive mode it is just displays the errors, doesn't enforce them, so that error is not indicative of the problem (i.e. SELinux is not what is blocking access to the .so).

Regarding the last part on 32-bit ... you said it does not work on the next attempt .. does that mean it works the first time, but not subsequently?
Comment 8 Jan Kratochvil 2009-02-24 15:55:23 EST
(In reply to comment #7)
> As for the SELinux errors -- in permissive mode it is just displays the errors,
> doesn't enforce them, so that error is not indicative of the problem (i.e.
> SELinux is not what is blocking access to the .so).

I am aware of it but AFAIK there are cases where the SELinux functionality differs even between Permissive<->Disabled.  It looked so in this case to me but as the results were nondeterministic anyway (see below) I cannot be certain.


> Regarding the last part on 32-bit ... you said it does not work on the next
> attempt .. does that mean it works the first time, but not subsequently?

It worked once, not sure if it was the first time.  IIRC I did even reboot it and it did not work even after the reboot.


The reproducibility is simple when you have some security-sandboxed system.
Comment 9 Deepak Bhole 2009-02-25 17:04:48 EST
Created attachment 333248 [details]
Screenshot of applet from www.mojebanka.cz loaded

I don't think those exceptions are a problem, because the applet code continues on after that, so it is probably more like a warning ... 

Despite those issues, the applet loads fine for me. Attached is a screenshot of what I see ... should I be seeing something else?
Comment 10 Deepak Bhole 2009-02-25 17:06:04 EST
The screenshot in comment #9 is on a 32-bit system by the way..
Comment 11 Jan Kratochvil 2009-02-25 17:11:30 EST
Yes, this screenshot means successful functionality.
(In reply to comment #10)
> The screenshot in comment #9 is on a 32-bit system by the way..

I was running x86_64 OS with firefox.i386 + openjdk.i386.  Is here a real user of the banking?
Comment 12 Martin Sourada 2009-02-26 11:00:51 EST
(In reply to comment #11)
> Yes, this screenshot means successful functionality.
> (In reply to comment #10)
> > The screenshot in comment #9 is on a 32-bit system by the way..
> 
> I was running x86_64 OS with firefox.i386 + openjdk.i386.  Is here a real user
> of the banking?

Yup. I am a real user. I can confirm it works now (epiphany + java-1.6.0-openjdk-plugin-1.6.0.0-9.b14.fc10.i386). The applet loads, I can log in and it seems to work.

Thanks for the fix.
Comment 13 Deepak Bhole 2009-02-26 16:50:28 EST
Great! So the problem now is only when 32-bit OpenJDK is used on 64-bit, correct?
Comment 14 Jan Kratochvil 2009-03-04 16:16:22 EST
Closing it as it works really fine (with 32-bit firefox+openjdk on x86_64 OS), sorry for the false reopen.


(In reply to comment #7)
> As for the SELinux errors -- in permissive mode it is just displays the errors,
> doesn't enforce them, so that error is not indicative of the problem (i.e.
> SELinux is not what is blocking access to the .so).

Confirming it works even in Permissive mode (although not in Enforcing mode).


> Regarding the last part on 32-bit ... you said it does not work on the next
> attempt .. does that mean it works the first time, but not subsequently?

Found out now the problem of my test - one needs to click / move mouse in the Firefox window.  When it runs with no user input - as I did run it in a VNC server which I only watched (never touched) - Firefox "hangs" indefinitely.  After clicking to the web page it always started working.
Comment 15 Martin Sourada 2009-03-04 17:15:37 EST
ct(In reply to comment #14)
> Closing it as it works really fine (with 32-bit firefox+openjdk on x86_64 OS),
> sorry for the false reopen.
> 
Actually I've just noticed it does not work in rawhide, but since I have selinux in Enforcing mode there, it might be bacause of that. But nevertheless java seems to start eating CPU cycles and does not seem to stop. I will recheck with SELinux in permissive mode.

> 
> (In reply to comment #7)
> > As for the SELinux errors -- in permissive mode it is just displays the errors,
> > doesn't enforce them, so that error is not indicative of the problem (i.e.
> > SELinux is not what is blocking access to the .so).
> 
> Confirming it works even in Permissive mode (although not in Enforcing mode).
> 
Yep, a lot of messages about text relocation (don't know what to think about that).

> 
> > Regarding the last part on 32-bit ... you said it does not work on the next
> > attempt .. does that mean it works the first time, but not subsequently?
> 
> Found out now the problem of my test - one needs to click / move mouse in the
> Firefox window.  When it runs with no user input - as I did run it in a VNC
> server which I only watched (never touched) - Firefox "hangs" indefinitely. 
> After clicking to the web page it always started working.
Interesting.

I've also noticed that it crashes a lot (after a rather intensive usage these past few days). I have the certificate I use to log in with on my pen drive and it crashes during applet loading if (and only if) I have the flash disk mounted. Also it instantly crashes after loging out (always). I'll probably open a new bug with more info when I'm back in F10.

But anyway, thanks for making this work!
Comment 16 Deepak Bhole 2009-03-04 18:32:56 EST
I wonder if the "always crash" after exit is related to Bug# 483095. I have fixed that upstream, and it will be in the next update (the one after the upcoming update).

Note You need to log in before you can comment on or make changes to this bug.