javax.smartcardio in zulu broken due to hardcoded libpcsclite.so path

[eliasp]

Issue description

Trying to use javax.smartcardio with zulu fails which seems to be caused by the fact, that the paths to the pcsclite shared-objects are hardcoded.

Steps to reproduce

1. Enable pcscd systemwide in configuration.nix and nixos-rebuild switch:

services.pcscd.enable = true;
services.pcscd.plugins = [ pkgs.pcsc-cyberjack ];

2. Check, whether the card reader itself is detected properly:

$ nix-shell --pure --packages pcsctools --run "pcsc_scan"
PC/SC device scanner
V 1.4.25 (c) 2001-2011, Ludovic Rousseau <[email protected]>
Compiled with PC/SC lite version: 1.8.23
Using reader plug'n play mechanism
Scanning present readers...
0: REINER SCT cyberJack pp_a (2362361144) 00 00

Tue Sep 18 17:06:19 2018
Reader 0: REINER SCT cyberJack pp_a (2362361144) 00 00

mkdir -p ~/DemoBug/
cd ~/DemoBug

4. Create DemoBug.java:

import java.util.List;
import javax.smartcardio.CardTerminal;
import javax.smartcardio.CardTerminals;
import javax.smartcardio.TerminalFactory;

public class DemoBug {

    public static void main(String[] args) {
        try {
            getReaders();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }    

    public static void getReaders() throws Exception {
        try {
            TerminalFactory fac = TerminalFactory.getDefault();
            CardTerminals terminals = fac.terminals();
            List<CardTerminal> list = terminals.list();
            if (list != null) {
                System.out.println("Number of terminals: " + list.size());
            } else {
                System.out.println("List is null.");
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }    
}

Java-Snippet based on example code from JDK-8026326

5. Build it

nix-shell --pure --packages zulu8 --run "javac DemoBug.java"

6. Run it

nix-shell --pure --packages zulu8 strace --run "strace -e stat,open -f -o DemoBug.out java DemoBug"

7. Analyze it:

grep '("/' DemoBug.out | cut -d\" -f2 | sort | uniq | grep ".so$"

Result:

/nix/store/h50vw4hcsq2jk843lzf20cdri8ffa8g7-zulu-8.21.0.1/jre/lib/amd64/libawt_xawt.so
/nix/store/h50vw4hcsq2jk843lzf20cdri8ffa8g7-zulu-8.21.0.1/jre/lib/amd64/libj2pcsc.so
/nix/store/h50vw4hcsq2jk843lzf20cdri8ffa8g7-zulu-8.21.0.1/jre/lib/amd64/libsunec.so
/nix/store/h50vw4hcsq2jk843lzf20cdri8ffa8g7-zulu-8.21.0.1/jre/lib/amd64/libzip.so
/nix/store/h50vw4hcsq2jk843lzf20cdri8ffa8g7-zulu-8.21.0.1/jre/lib/amd64/server/libjvm.so
/nix/store/h50vw4hcsq2jk843lzf20cdri8ffa8g7-zulu-8.21.0.1/jre/lib/amd64/xawt/libmawt.so
/nix/store/h50vw4hcsq2jk843lzf20cdri8ffa8g7-zulu-8.21.0.1/jre/lib/ext/amd64/libsunec.so
/nix/store/h50vw4hcsq2jk843lzf20cdri8ffa8g7-zulu-8.21.0.1/jre/lib/ext/libsunec.so
/usr/lib64/libpcsclite.so
/usr/local/lib64/libpcsclite.so

Dissecting zulu-8.21.0.1 showed, that the paths /usr/lib64/libpcsclite.so and /usr/local/lib64/libpcsclite.so are defined in /nix/store/h50vw4hcsq2jk843lzf20cdri8ffa8g7-zulu-8.21.0.1/jre/lib/rt.jar, which again contains sun/security/smartcardio/PlatformPCSC.class where those paths are coming from:

$ strings /tmp/rt.jar/rt/sun/security/smartcardio/PlatformPCSC.class | grep libpcsclite.so                 
/usr/$LIBISA/libpcsclite.so
!/usr/local/$LIBISA/libpcsclite.so

Technical details

Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

 - host os: `Linux 4.14.67, NixOS, 18.03.133231.01f5e794913 (Impala)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.0.4`
 - channels(root): `"nixos-18.03.133231.01f5e794913, unstable-19.03pre152634.218ce4de508"`
 - channels(eliasp): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs`

[qknight]

maybe use patchelf here?

[eliasp]

patchelf won't work, as that's Java bytecode within a *.jar file - looking into other possibilities you suggested, such as:

• intercepting & diverting stat() and open() syscalls via a LD_PRELOAD hack
• simply using LD_LIBRARY_PATH to point to the correct path (unlikely to work, as it seems it only tests for those hardcoded paths)

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[StarGate01]

I found a workaround which works for my system, set the sun.security.smartcardio.library JVM argument in the default Java runtime arguments:

environment.sessionVariables = {
    _JAVA_OPTIONS = "-Dsun.security.smartcardio.library=${lib.getLib pkgs.pcsclite}/lib/libpcsclite.so";
};

Each time I run a java application, the JVM reports

Picked up _JAVA_OPTIONS: -Dsun.security.smartcardio.library=/nix/store/0cdj8mkp03sh1yw9bnkg1sircj99scvp-pcsclite-1.9.5/lib/libpcsclite.so

and the library is able to interface PCSC correctly.

See also: https://stackoverflow.com/questions/12376257/accessing-javax-smartcardio-from-linux-64-bits