1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/opensc/README Thu Mar 15 21:52:52 2012 +0100
1.3 @@ -0,0 +1,37 @@
1.4 +NOTE
1.5 +
1.6 +It seems there are problems with opensc(5) and pcscd(8) coexistence.
1.7 +
1.8 +It has been observed that pcscd(8) performs correctly in the absence
1.9 +of /usr/lib/opensc-pkcs11.so. Namely, pcscd(8) does not run until a
1.10 +end user accesses the smart card harware using a client application.
1.11 +Once this happens, pcscd(8) starts with user and group permissions
1.12 +of the end user and the client application procedes normally.
1.13 +
1.14 +Should /usr/lib/opensc-pkcs11.so be present, pcscd(8) starts at
1.15 +system boot with root privileges. Once a end user accesses the smart
1.16 +card hardware, a second instance of pcscd(8) is launched, the script
1.17 +/etc/init.d/pcscd is executed with the end user's user and group
1.18 +permissions. The script causes deletion of /var/run/pcscd where
1.19 +important connection information is stored by the first pcscd(8)
1.20 +instance running with root privileges. It may be this deletion
1.21 +which causes all client applications to fail to access the smart
1.22 +card hardware.
1.23 +
1.24 +The workaround is to manually edit the script /etc/init.d/pcscd
1.25 +so that /var/run/pcscd is not removed, but this appears to be
1.26 +a short lived hack. Adequate testing has not proven this approach
1.27 +to be correct.
1.28 +
1.29 + # FIXME: Fat bug, don't overwrite important
1.30 + # FIXME: preexisting pcscd(8) connection data!
1.31 + [ -e $IPCDIR/$NAME.comm ] && exit 0
1.32 +
1.33 +SCDAEMON BLOCKED
1.34 +
1.35 +Problems exist when using applications calling scdaemon(8) which
1.36 +locks access to the card reader. No solution exists, rather a
1.37 +workaround is to forcefully kill the scdaemon(8) server. This
1.38 +is a problem for those users of gpg(1) because of its indirect
1.39 +usage of scdaemon(8) and inability to call opensc(5) for any
1.40 +PKCS functions.
