Conflict Due to Multiple Instances of Smart Card Daemon

muredanta muredanta at protonmail.com
Tue May 21 04:53:45 CEST 2019


Hello,
I'm building an application that configures smart cards (currently Yubikeys) as OpenPGP cards using GPGME and the gpgme_op_interact() API. In order to provide the functions needed at the user level, I need to engage in several different interactions, most notably some that emulate --card-edit and others with --edit-key. Because the first has no key associated with it, while the second requires a key, the second argument to gpgme_op_interact() is either NULL or a pointer to a gpgme_key_t, respectively.

This seems to be the origin of a problem I am seeing. While the first operations (--card-edit) work fine, when I try to perform the second set of operations (--edit-key), I get an error. At the API level, this manifests as a CARDCTRL 4 response to the gpgme_op_interact() session, meaning that no card is available, though clearly the card is there. If I follow the chain of operations to find out why GNUPG thinks the card is not available, the ultimate source seems to be that, when the initial set of (--card-edit) operations were done, an instance of scdaemon was spawned, and that daemon continues to run even after the operations have finished. Later, when the second set of (--edit-key) operations begin, because the arguments are different (I'm guessing), a second instance of scdaemon is spawned. But this second instance cannot access the card because the first instance still holds some kind of exclusive lock on access to the card. As a result what I get from the second (newer) instance of scdaemon is a message "pcsc_connect failed: sharing violation (0x8010000b).

As a result of this, the only current way to use the API to configure the card is to have the user remove and re-insert the card, and unfortunately depending on the series of operations they want to perform (which could include reading cards, erasing them, configuring them, etc), this can be required multiple times, which obviously isn't ideal, so I wonder if there is a solution?

One possibility would be to arrange things so that the different instances of scdaemon could effectively share access to the card. I see in scd/apdu.c:connect_pcsc_card() that there is an option to pcsc_connect() which is currently set to PCSC_SHARE_EXCLUSIVE, but there are alternatives (PCSC_SHARE_SHARED and PSCS_SHARE_DIRECT).

Another more "violent" option would be if there is some way to force the termination of the first scdaemon instance before begining the next one, say, a call like gpgme_op_interact_cleanup() or something like that.

Or perhaps there is another way that I just haven't seen yet. Do you have any suggestions?

Thanks very much!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190521/e1ffbf5f/attachment-0001.html>


More information about the Gnupg-users mailing list