libpcsclite1: card detection no longer works since 1.7.4-2ubuntu2

[Martin-Éric Racine]

Since multiarch support was introduced in 1.7.4-2ubuntu2, cards inserted into the card reader fail to be detected.

One easy test is with OpenSC's 'opensc-tool -f'. On 1.7.4-2ubuntu1, it returns the card's content in raw HEX format. On 1.7.4-2ubuntu2, it instead returns "No smart card readers found."

This is on an x86-32 host.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libpcsclite1 1.7.4-2ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic-pae 3.2.14
Uname: Linux 3.2.0-23-generic-pae i686
ApportVersion: 2.0.1-0ubuntu1
Architecture: i386
Date: Wed Apr 11 17:38:49 2012
ProcEnviron:
 LANGUAGE=fi_FI:en
 TERM=xterm
 PATH=(custom, user)
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
SourcePackage: pcsc-lite
UpgradeStatus: No upgrade log present (probably fresh install)

[Ludovic Rousseau (ludovic-rousseau+ubuntu-one)]

I guess the problem is that OpenSC do not find the libpcsclite.so.1 library.
The problem is not with the card but with the way OpenSC uses the PC/SC library.

OpenSC uses dlopen() to load the library. Maybe dlopen() should be modified to support Multi Arch. Or the problem is elsewhere.

[Matthias Klose (doko)]

please do better:
 - strace the call, see where/why it fails to dlopen the library
 - run the tool with -v -v -v

[Martin-Éric Racine (q-funk)]

The attached strace output is rather self-explanatory.

Btw, I seem to recall that Ubuntu had purposely deviated from installing libraries in /usr/lib and instead reverted to /lib so as to be able to support SmartCard-enabled network authentication upon bootup. I guess the question is, is there a multi-arch path in FHS that happens to be in / rather than /usr that we can use?

[Ludovic Rousseau (ludovic-rousseau+ubuntu-one)]

Martin-Eric, what is the result of:
$ grep provider_library /etc/opensc/opensc.conf

[Martin-Éric Racine (q-funk)]

$ grep provider_library /etc/opensc/opensc.conf
  # provider_library = /lib/libpcsclite.so.1

That's evidently a hard-coded path. No wonder this doesn't work with multi-arch!

[Steve Langasek (vorlon)]

Reproducible without special hardware. strace shows:

open("/etc/opensc/opensc.conf", O_RDONLY) = 3
open("/lib/libpcsclite.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

and /etc/opensc/opensc.conf has:
        reader_driver pcsc {
                [...]
                # Use specific pcsc provider.
                # Default: /lib/libpcsclite.so.1
                # provider_library = /lib/libpcsclite.so.1
        }

So it looks like this is an opensc bug, for hard-coding a library path internally.

[Matthias Klose (doko)]

opensc currently fails to build for other reasons:

https://launchpad.net/ubuntu/+archive/test-rebuild-20120328/+build/3352168

[Matthias Klose (doko)]

introduced in:

opensc (0.11.12-1ubuntu2) lucid; urgency=low

  [ Dominik Fischer ]
  * debian/rules: build with "--with-pcsc-provider=/lib/libpcsclite.so.1",
    as this is the path of libpcsclite in jaunty and above.
  * opensc.install: added westcos-tool + manpage

 -- Steve Langasek <email address hidden> Thu, 18 Feb 2010 02:52:33 -0800

dlopen should be able to load that without any specific path.

[Launchpad Janitor (janitor)]

This bug was fixed in the package opensc - 0.12.1-1ubuntu5

---------------
opensc (0.12.1-1ubuntu5) precise; urgency=low

  * Don't configure with --with-pcsc-provider. LP: #978974.
 -- Matthias Klose <email address hidden> Wed, 11 Apr 2012 20:06:48 +0200