While debugging split-pkcs11 configuration I encountered an unpleasant issue.
Say, I have a remoting service in a target qube that provides simple access to a socket:
/usr/bin/nc -U /tmp/pkcs11.socket
and I have a client service, be it systemd sockets or now, for simplicity’s sake, let’s consider a ncat:
ncat -k -l -U /run/user/1000/p11-kit/pkcs11 -c “/usr/bin/qrexec-client-vm core-usb liteqube.pkcs11”.
everything runs just fine until client socket closes the connection. what happens then?
ncat sends EOF to qrexec-client-vm
qrexec-client-vm sends EOF up to the socket and waits for p11-kit to send the remaining data and close
p11-kit sends the remaining data and ignores EOF, waiting for the socket to actually close and destroy
qrexec-client-vm relays the data and waits for p11-kit forever to close.
Thus, we have qrexec-client-vm instance stuck and p11-kit instance waiting for data from it.
Could it be fixed without implementing yet another wrapper?
Yes, I know that I can use modules remoting instead of sockets remoting and that would be quick fix. But I want a scalable solution for all socket-forwarding services to work properly.