From the pkcs11-helper API documentation about pkcs11h_setForkMode():
> This funciton is releavant if PKCS11H_FEATURE_MASK_THREADING is
> set. If safe mode is on, the child process can use the loaded
> PKCS#11 providers but it cannot use fork(), while it is in one of
> the hooks functions, since locked mutexes cannot be released.
As far as I can tell, pkcs11-helper functionality is not used in a
child process that is created after initialization. Even if OpenVPN is
turned into a daemon, the pkcs11-helper library is only initialized
after calling possibly_become_daemon(), i.e. in the child process. All
other uses of fork() are immediately followed by an exec()
This simple change fixes the symptoms described in both
<https://community.openvpn.net/openvpn/ticket/538> (hang on password
prompt when systemd support is enabled) and
<https://community.openvpn.net/openvpn/ticket/1157> (hang on
initialization with newer versions of pkcs11-helper).
I have successfully tested that this makes the described symptoms go
away. For this, I used a YubiKey NEO on Debian/stable, a rebuild of
OpenVPN 2.4.6 and two versions of libpkcs11-helper:
- libpkcs11-helper 1.21-1 from Debian/stretch
- a backport of libpkcs11-helper 1.25-1 from Debian/buster
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <
20190218153129.3818-1-bengen@hilluzination.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18218.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>