[MacOS] OpenVPN fails to use crypto token when run daemonized

[z80a]

Hi,

I’m willing to deploy OpenVPN, authentified with hardware crypto tokens, on MacOS X clients, with Tunnelblick GUI. Unfortunately, it fails, as discussed on ​https://groups.google.com/forum/#!topic/tunnelblick-discuss/f_Rp_2nV-x8.

I investigated a bit, and found out that the problem occurs only when OpenVPN is run daemonized.
I could dig the issue up to a call, by the PKCS#11 library, to the SCardEstablishContext PC/SC function, which returns SCARD_E_NO_SERVICE (“The Smart card resource manager is not running.”) when OpenVPN is run daemonized, and SCARD_S_SUCCESS when it’s not daemonized.

It seems to me that the problem should be related to the way OpenVPN daemonizes itself.

I know little about MacOS (I’m more a Linux guy), but I’d be happy to help investigate this issue.

I have no idea whether this issue is MacOS-specific. I run my tests with MacOS Sierra 10.12.6.

[z80a]

Hi,

I could investigate the issue a little further, and found it should be related to the problem described by Ludovic Rousseau in his blog post: ​https://ludovicrousseau.blogspot.fr/2015/11/os-x-el-capitan-bug-pcsc-not-usable.html.

If that’s right, the problem should not occur with OS X Yosemite or earlier, or with PKCS#11 libraries that do not use PC/SC (like software-only PKCS#11 libraries).

If I understand it correctly, that is an issue that Apple is not willing to fix in his PC/SC implementation… It looks like OpenVPN needs to “exec [it]self” after forking. Unless I’m missing something, it means that OpenVPN would have to exec itself, and then re-parse its arguments and any included configuration file, which looks quite inefficient (not to say stupid).

[Gert Döring]

I think we might have even fixed this en passant by changing the order we do fork() (daemon()) and SSL library initialization.

Can you re-test if this still happens with 2.5 or 2.6_beta2?