First, the PKCS #11 spec is silent on this issue particularly, but it is clear about one thing, you do need to be able to handle C_Initialize after the fork. The quickest way to get there is to allow shutdown.
Second, the primary impediments for allowing this I have heard are two-fold:1) Thread locks may be held in the parent causing issues in the client. --- and ---
2) Shared file descriptors between the parent and client.I would like to point out the following, however: First, neither of these issues affect existing NSS applications. Any application that forked softoken before would have tripped over these if there had been an issue. Children would have locked up if they used NSS and the parent held locks when it forked. If the parents were actively using those file descriptors, then we would have already tripped over these issues.
Given this, I think allowing shutdown after a fork, then renabling the ability to call C_Initialize() is the right thing. Better would be to automatically call shutdown from C_Initialize if it is called after a fork. I don't think we need to come up with the optimal solution to the problem before we implement something that better meets the PKCS #11 spec.
Finally, I would like to point out that We can mitigate issues with the file descriptors in the following ways: 1) if the database was opened read only, we can safely close it, not data is written to the database.
2) if the database was opened R/W, we could skip any sync() before close.3) if we are worried about either 1 or 3, we could simple 'drop' the open database handles (leak them). In fact we could do the same for any locks as well. Shutdown itself does not need locks. If we are shutting down after a fork() we could drop database handles opened R/W, and leak locks which are held.
In fact we are doing these things already when we refuse to shutdown. I propose we do the following:1) immediately allow Shutdown after a fork. -- this will reenable applications, and bring us closer to the PKCS #11 spec (which requires us to be able to initialize after a fork()). 2) Add code so we can simply reinit after a fork (by automatically calling shutdown after the first C_Initialize after a fork). 3) Implement code in shutdown to tolerate open file descriptors which may still be active in the parent and held locks.
I think 1 is sufficient for now, 2 is highly desirable, and 3 depends on what level of 'correctness' we need in the future (should not be relevant for existing applications).
bob
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
