Re: [Opensc-devel] Towards release 0.15.0

[David W. <dw...@in...>]

On Tue, 2015-05-12 at 11:43 +0200, Frank Morgner wrote:
> 
> Is this identical to https://github.com/OpenSC/OpenSC/issues/333 ;? 


It's closely related, at least.

It all stems from the recommendation in the PKCS#11 Usage Guide that a
process should call C_Initialize() on loaded modules immediately after
forking.

> As far as I can see from the github issue, #333 is a problem in
> Apple's PC/SC implementation

I'm not entirely sure where the finger should be pointed. Quite
frankly, it would be better just not to make the pointless call to
C_Initialize() when *all* we are going to do after forking is exec
something else. I actually have a cheap hack to 'fix' the problem in
OpenVPN just by using vfork() instead of fork(), so the problematic
pthread_atfork() handler doesn't run :)

OpenSC is potentially implicated here, because after a fork it is
confusing PC/SC by continuing to let both parent and child talk to
pcscd over the same RPC mechanism. Or maybe PC/SC isn't "confused" per
se — maybe the child tells it to power down the card, and the parent
then continues to try to use it?

In the OSX case shown in #333 it seem OSX has a different RPC
mechanism for talking to PC/SC than Linux, and when OpenSC misuses the
parent's connection from the child there's actually a crash in the RPC
library.

That crash certainly shouldn't happen, and looks like a PC/SC bug.
But I think it's still really an OpenSC issue.

> Also, please open a PR with your example code on github to get feedback.
> Then this issue doesn't lost in some mail archive.

I've updated #333 with a reference to the test case and noted that it
occurs on Linux too.

-- 
dwmw