Bug 673228

Summary:	RFE alternative way to handle misbehaving applications that expext nss context to live after a fork()
Product:	[Fedora] Fedora	Reporter:	Simo Sorce <ssorce>
Component:	nss-softokn	Assignee:	nss-nspr-maint <nss-nspr-maint>
Status:	CLOSED DEFERRED	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	dueno, rmeggins, rrelyea
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-24 16:21:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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.