Created attachment 313183 [details]
Terminal output from the login page

Created attachment 313184 [details]
Terminal output from the  Configuration Wizard page

Heh, I thought this was a feature to protect me from spending money unnecessarily.

*** This bug has been marked as a duplicate of bug 304021 ***

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)

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.

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?

(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.

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?

The screenshot in comment #9 is on a 32-bit system by the way..

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?

(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.

Great! So the problem now is only when 32-bit OpenJDK is used on 64-bit, correct?

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.

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!

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).