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