On Wed, 2015-05-06 at 22:06 +0200, David Sommerseth wrote: > > All patches has been tested locally with different configurations, > requiring username, password and passphrases to PKCS#12 files. The > challenge/response interface has not been tested, as well as PKCS#11. > All runs via valgrind shows no memory leaks with this new > implementation.
I've given some pointers in ticket 538 on how you can test PKCS#11
without actually having a hardware token — you can use GNOME keyring in many
cases, or in this case where you really want to test
password input,
you can use a NSS "softokn" database.
Even if I make these patches build by fixing the issue that leads to
libsystemd_MODVERSION being set to '219\n219' when both systemd.pc and
libsystemd.pc exist, they still don't solve the problem described in
that ticket.
You are still calling fork() from a context (the PIN request callback
from pkcs11-helper) in which it is forbidden, and in which it
deadlocks:
#2 0x00007ffff7d9c096 in _pkcs1h_threading_mutexLockAll () at
pkcs11h-threading.c:306
#3 0x00000038412c8362 in __libc_fork () at ../sysdeps/nptl/fork.c:89
#4 0x0000003841a0f4a5 in __fork () at pt-fork.c:25
#5 0x000000000042893b in openvpn_popen (a=a@entry=0x7fffffff9be0,
es=es@entry=0x0) at misc.c:374
#6 0x000000000046f0e8 in get_console_input_systemd (capacity=4096,
input=0x7fffffffb1f2 "", echo=false,
prompt=0x73cdc8 "Enter PIV_II (PIV Card Holder pin) token Password:") at
console_systemd.c:72
#7 query_user_exec (setup=<optimized out>) at console_systemd.c:111
#8 0x0000000000427aed in get_user_pass_cr (up=up@entry=0x7fffffffa1f0,
auth_file=<optimized out>, auth_file@entry=0x0,
prefix=prefix@entry=0x7fffffff9df0 "PIV_II (PIV Card Holder pin) token",
flags=flags@entry=21, auth_challenge=auth_challenge@entry=0x0) at misc.c:1144
#9 0x0000000000435711 in get_user_pass (flags=21, prefix=0x7fffffff9df0
"PIV_II (PIV Card Holder pin) token", auth_file=0x0, up=0x7fffffffa1f0) at
misc.h:268
#10 _pkcs11_openvpn_pin_prompt (global_data=<optimized out>,
user_data=<optimized out>, token=<optimized out>, retry=<optimized out>,
pin=0x7fffffffc250 "K{`f=",
pin_max=1024) at pkcs11.c:236
#11 0x00007ffff7d9e0cb in _pkcs11h_session_login (session=0x6e9220,
is_publicOnly=is_publicOnly@entry=0, readonly=readonly@entry=1, user_data=0x0,
mask_prompt=<optimized out>) at pkcs11h-session.c:1023
Perhaps the solution might be to *always* operate in 'management
interface' mode, and to shift all the direct console access out to a
separate process. *That* process would be permitted to run fork(),
when the core OpenVPN process requests a password...
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
