Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token

[hyc@symas.com]

richm@stanfordalumni.org wrote:
> On Sat, Jan 29, 2011 at 3:26 AM,<hyc@symas.com>  wrote:
>> rmeggins@redhat.com wrote:
>>> Full_Name: Rich Megginson
>>> Version: 2.4.23 (current CVS HEAD)
>>> OS: RHEL6
>>> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofo=
> rk-20110127.patch
>>> Submission from: (NULL) (76.113.111.209)
>>>
>>>
>>> There are some applications that acquire a crypto context in the parent =
> process
>>> and expect that crypto context to work after a fork(). =A0This does not =
> work
>>> with MozNSS using strict PKCS11 compliance mode. =A0We set the environme=
> nt
>>> variable NSS_STRICT_NOFORK=3DDISABLED in tlsm_init() to tell the softwar=
> e
>>> encryption module/token to allow crypto contexts to persist across a for=
> k().
>>> However, if you are using some other module or encryption device that su=
> pports
>>> and expects full PKCS11 semantics, the only recourse is to modify the
>>> application to use atfork() handlers to save the crypto context in the p=
> arent
>>> and restore (and SECMOD_RestartModules) the context in the child.
>>
>> Sounds like this is a followon to #6802. Is this really critical at this
>> point? We really need to close the window on RE24 patches so we can actua=
> lly
>> cut a release. But if ITS#6802 is actually incomplete, I guess we should =
> roll
>> this in.
>
> Yes, it is a followon to 6802 - as it turns out, the patch to 6802 was
> incomplete.  We have discovered some important applications such as
> sshd/su/others that open an LDAP* connection in the parent process,
> fork(), and attempt to use the same LDAP* handle in the child.  Some
> of the other Fedora/Red Hat developers and I had a discussion with one
> of the MozNSS developers about this issue, as ldap is not the only
> affected area.  It was decided that the best thing is to simply
> disable the fork() checking in the MozNSS software token pkcs11 crypto
> module.  This will give us parity with openssl with respect to fork()
> behavior.  It is a critical issue for Fedora/Red Hat.  I understand
> that this is coming in late in the game and you may not be able to get
> this into RE24.  If not, Fedora/Red Hat will carry a patch for this.

Is this env var and atfork() workaround already documented in the NSS 
documentation? Just wondering if we need to say anything about it in our Admin 
Guide, FAQ-o-Matic, or manpages.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/