<div dir="ltr"><div><div><div>Hi,<br><br></div>Thank you for describing the impersonation mechanism.<br>However, stating "find a better PKCS#11 provider" is not the way to go.<br></div>It seems you are making wrong assumptions related to the PKCS#11 standard, "fork" related behaviour (section 6.6.1) is described as follows:<br><div style="margin-left:40px">"In general, on most platforms, the previous paragraph means that an<br>application consists of a single process. Consider a UNIX process P<br>which becomes a Cryptoki application by calling C_Initialize,<br>and then uses the fork() system call to create a child process C.<br>Since P and C have separate address spaces (or will when one of them<br>performs a write operation, if the operating system follows the copy-on-write<br>paradigm), they are not part of the same application. Therefore, if C needs<br>to use Cryptoki, it needs to perform its own C_Initialize call. Furthermore,<br>if C needs to be logged into the token(s) that it will access via Cryptoki,<br>it needs to log into them even if P already logged in, since P and C are<br>completely separate applications. In this particular case (when C is the<br>child of a process which is a Cryptoki application), the behavior of<br>Cryptoki is undefined if C tries to use it without its own C_Initialize call.<br>Ideally, such an attempt would return the value CKR_CRYPTOKI_NOT_INITIALIZED;<br>however, because of the way fork() works, insisting on this return value might have a<br>bad impact on the performance of libraries.<br>Therefore, the behavior of Cryptoki in this situation is left undefined.<br>Applications should definitely not attempt to take advantage of any potential<br>"shortcuts" which might (or might not!) be available because of this.<br>In the scenario specified above, C should actually call C_Initialize whether<br>or not it needs to use Cryptoki; if it has no need to use Cryptoki, it should<br>then call C_Finalize immediately thereafter.<br>This (having the child immediately call C_Initialize and then<br>C_Finalize if the parent is using Cryptoki) is considered to be good<br>Cryptoki programming practice, since it can prevent the existence of dangling<br>duplicate resources that were created at the time of the fork() call; however,<br>it is not required by Cryptoki."<br></div><br>Now, assuming a PKCS#11 provider provides a shortcut to re-initialize resources across a fork is a wrong assumption since the behaviour is left undefined. Furthermore, in most cases and given my experience with PKCS#11, you have to re-initialize the whole library (i.e., login again, find objects, etc).<br><br></div><div>Is there no better way to handle this case in nginx ?<br></div><div><br></div><div>Regards,<br><br></div><div>Thomas Calderon<br></div><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 10, 2015 at 12:30 PM, Dmitrii Pichulin <span dir="ltr"><<a href="mailto:pdn@cryptopro.ru" target="_blank">pdn@cryptopro.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a common behavior for security providers that do not have own service running, which can handle objects globally.<br>
<br>
nginx loads private keys once then forks then impersonates to user in config (if set).<br>
<br>
In your case, it seems that your PKCS#11 library does not support a fork or a user change.<br>
<br>
You can try to run nginx and its worker processes by the same user (<a href="http://nginx.org/en/docs/ngx_core_module.html#user" target="_blank">http://nginx.org/en/docs/ngx_<u></u>core_module.html#user</a>).<br>
<br>
Or you can try to find a better PKCS#11 provider.<div class="HOEnZb"><div class="h5"><br>
<br>
On 10.04.2015 13:00, Thomas Calderon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I just tried nginx PKCS#11 support that was introduced in 1.7.9.<br>
<br>
In a Debug/Test environment I have a working setup. Namely, using<br>
"daemon off" and the instructions provided on the mailing list, I manage<br>
to establish a TLS connection using my token.<br>
<br>
However, when using "daemon on", a client connection spawn the<br>
worker_process, the PKCS#11 library gets reloaded. However, the PKCS#11<br>
context is lost, hence the TLS connection cannot be established (further<br>
function fails since the library is not initilized, objects handles are<br>
not valid anymore, etc).<br>
<br>
Given the stack used to leverage PKCS#11 support<br>
(OpenSSL->engine_pkcs11->...), I am not sure how to fix this.<br>
<br>
Did you observe the same behavior ?<br>
<br>
Cheers,<br>
<br>
Thomas Calderon<br>
</blockquote>
</div></div></blockquote></div><br></div>