opensc/README

Thu, 15 Mar 2012 21:52:52 +0100

author
Michael Schloh von Bennewitz <michael@schloh.com>
date
Thu, 15 Mar 2012 21:52:52 +0100
changeset 4
b696a44762ea
permissions
-rw-r--r--

Import custom package specs to build for undistributed platforms.

michael@4 1 NOTE
michael@4 2
michael@4 3 It seems there are problems with opensc(5) and pcscd(8) coexistence.
michael@4 4
michael@4 5 It has been observed that pcscd(8) performs correctly in the absence
michael@4 6 of /usr/lib/opensc-pkcs11.so. Namely, pcscd(8) does not run until a
michael@4 7 end user accesses the smart card harware using a client application.
michael@4 8 Once this happens, pcscd(8) starts with user and group permissions
michael@4 9 of the end user and the client application procedes normally.
michael@4 10
michael@4 11 Should /usr/lib/opensc-pkcs11.so be present, pcscd(8) starts at
michael@4 12 system boot with root privileges. Once a end user accesses the smart
michael@4 13 card hardware, a second instance of pcscd(8) is launched, the script
michael@4 14 /etc/init.d/pcscd is executed with the end user's user and group
michael@4 15 permissions. The script causes deletion of /var/run/pcscd where
michael@4 16 important connection information is stored by the first pcscd(8)
michael@4 17 instance running with root privileges. It may be this deletion
michael@4 18 which causes all client applications to fail to access the smart
michael@4 19 card hardware.
michael@4 20
michael@4 21 The workaround is to manually edit the script /etc/init.d/pcscd
michael@4 22 so that /var/run/pcscd is not removed, but this appears to be
michael@4 23 a short lived hack. Adequate testing has not proven this approach
michael@4 24 to be correct.
michael@4 25
michael@4 26 # FIXME: Fat bug, don't overwrite important
michael@4 27 # FIXME: preexisting pcscd(8) connection data!
michael@4 28 [ -e $IPCDIR/$NAME.comm ] && exit 0
michael@4 29
michael@4 30 SCDAEMON BLOCKED
michael@4 31
michael@4 32 Problems exist when using applications calling scdaemon(8) which
michael@4 33 locks access to the card reader. No solution exists, rather a
michael@4 34 workaround is to forcefully kill the scdaemon(8) server. This
michael@4 35 is a problem for those users of gpg(1) because of its indirect
michael@4 36 usage of scdaemon(8) and inability to call opensc(5) for any
michael@4 37 PKCS functions.

mercurial