scdaemon PC/SC OPEN failed: sharing violation (0x8010000b)
Closed, WontfixPublic

Description

We have received a bug report from a user, which I am going to post, since it accurately describes the problem:

My hardware token (YubiKey NEO) has several applets, including PIV and OpenPGP. Needless to say, I need and use both of them.

On Mac OS X, tokend connects to the token immediately upon its insertion, which is necessary to present the token as a (PIV) keychain in the Keychain Access, and make its keys/certificates otherwise available to the Mac OS X applications.
However, when I try to use gpg, or any component of GPGTools that needs access to this token (to its OpenPGP applet), this tool detects that the token is already being used - and refuses to connect to it, with the following messages in the /tmp/scdaemon.log:
016-09-06 21:09:24 scdaemon[67807] PC/SC OPEN failed: sharing violation (0x8010000b)
2016-09-06 21:09:24 scdaemon[67807] PC/SC OPEN failed: sharing violation (0x8010000b)
2016-09-06 21:09:33 scdaemon[67807] PC/SC OPEN failed: sharing violation (0x8010000b)

Expected
I would expect and like sharing - especially since they share the “token” but not the “applet”: PIV applications cannot use OpenPGP interface, and vs. versa (I think).
I know about the design ideology (security concerns), but this kills usability, particularly with Apple Mail, where I need to process both PGP-protected and S/MIME-protected emails (obviously from different crowds, but that is not relevant).
Same applies to Thunderbird, except there is no tokend involved - just inability of GPG Suite to share the token with PIV suite. I’d like it remedied.

Additional info
There is a workaround - but it is ugly: insert the token, start Apple Mail, process all the S/MIME emails. Quit Mail, kill OpenSC.tokend. Run “gpg2 —card-status” (assuming it connects and provides expected result). Start Mail, process PGP/MIME emails. Quit Mail, remove the token, re-insert it - now PIV and S/MIME are functioning again.
Ugly as a mule. Can you please either remove this restriction, or better yet - add a configuration parameter that would allow token sharing?

Seems in 2005 the same bug has been filed for Windows OS: T412

A workaround is documented here: https://www.nitrokey.com/documentation/frequently-asked-questions#how-to-make-gnupg-release-exclusive-smartcard-access

Seems Jan (nitrokey) has requested this in 2015: https://lists.gnupg.org/pipermail/gnupg-devel/2015-August/030245.html

Also discussed in the OpenSC tracker 2017: https://github.com/OpenSC/OpenSC/issues/953

Details

Version
2.1.21
steve created this task.Mon, Jul 10, 3:18 PM
werner edited projects, added scd, FAQ; removed Bug Report.Mon, Jul 10, 4:24 PM
werner closed this task as Wontfix.
werner claimed this task.
werner added a subscriber: werner.

This is on purpose. Please read the discussions. Use card-timeout in scdaemon.conf or "gpgconf --kill scdaemon"

werner updated the task description. (Show Details)Mon, Jul 10, 4:26 PM
Mouse added a subscriber: Mouse.Mon, Jul 17, 10:47 PM

@werner I request re-consideration. I *have* read the discussion, and remain convinced that a parameter that allows shared access is necessary.

Card timeout did not help. Rigmarole with killing daemons and re-inserting cards (and often having to restart applications like Apple Mail) just does not make sense - and is less that 100% reliable. Especially when a better way is possible.

Why not make it parameter-configurable? Exclusive access by default, shared access when the user (who knows what he is doing) wants it?