Thu, 15 Mar 2012 21:52:52 +0100
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. |