Bug 673228 - RFE alternative way to handle misbehaving applications that expext nss context to live after a fork()
Summary: RFE alternative way to handle misbehaving applications that expext nss contex...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: nss-softokn
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: nss-nspr-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-27 18:58 UTC by Simo Sorce
Modified: 2019-06-04 21:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-24 16:21:52 UTC
Type: ---


Attachments (Terms of Use)

Description Simo Sorce 2011-01-27 18:58:30 UTC
Currently, the only way to handle context reuse after fork() in applications is to set the NSS_STRICT_NOFORK=DISABLED environment variable.

It would be useful to have an alternative method, possibly as a system wide setting, so that this behavior can be set as default without depending on environment variables, which could be wiped out easily (for example using execve in an ancestor process)

Having a system wide setting, that causes nss to log something when the contexts not reinitialized after a fork() would help to identify misbehaving applications/libraries without having them break in the common case where a hardware token is not being used, allowing for a smoother transition.

Comment 1 Fedora Admin XMLRPC Client 2016-08-15 15:51:22 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Daiki Ueno 2019-05-23 12:29:46 UTC
What is the actual use-case of this? As far as I understand it this is to enforce C_Initialize() after fork() as suggested in the PKCS #11 standard. If this is causing problem, that means the caller (NSS) is not behaving courteously.

Comment 3 Simo Sorce 2019-05-24 16:21:52 UTC
This is a very old bug, I think uses that were affected has been discontinued, so I am going to close this bug at this point.

Comment 4 Bob Relyea 2019-06-04 21:12:19 UTC
There is also  a way of handling things after a fork. If you set an @fork handler and call: SECMOD_RestartModules(PR_FALSE); This does a C_Shutdown and C_Initialize on all the modules that 'need' restarting (NSS tries calling C_GetSlotList to see if the module needs restarting). It's safe to call multiple times and only does a restart if the module needs restarting. If the module does need restarting, all the key and cert handles are invalidated.

Anyway PKCS #11 3.0 has an optional fork safe interface which we can start using once it's approved.


Note You need to log in before you can comment on or make changes to this bug.