Bug 731168 - NSS_Init* functions are not thread safe
Summary: NSS_Init* functions are not thread safe
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap
Version: 6.1
Hardware: All
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Jan Vcelak
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On: 731112
Blocks: 790913
TreeView+ depends on / blocked
 
Reported: 2011-08-16 19:58 UTC by Jan Vcelak
Modified: 2013-03-04 01:29 UTC (History)
10 users (show)

Fixed In Version: openldap-2.4.23-18.el6
Doc Type: Bug Fix
Doc Text:
- openldap-servers package is installed, TLS is enabled, multiple TLS operations are performed by clients or other replicated servers - the server will crash with segmentation fault - fix was applied which adds mutex to protect calling of Mozilla NSS initialization functions, which are not thread safe - the server will no longer crash when initializing TLS because of thread races
Clone Of: 731112
Environment:
Last Closed: 2011-12-06 11:49:43 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1514 normal SHIPPED_LIVE openldap bug fix and enhancement update 2011-12-06 00:51:20 UTC

Description Jan Vcelak 2011-08-16 19:58:57 UTC
+++ This bug was initially created as a clone of Bug #731112 +++

Description of problem:
    The NSS_InitContext et. al, and their corresponding shutdown functions,
    are not thread safe.  There can only be one thread at a time calling
    these functions.  Protect the calls with a mutex.  Create the mutex
    using a PR_CallOnce to ensure that the mutex is only created once and
    not used before created.  Move the registration of the nss shutdown
    callback to also use a PR_CallOnce.  Removed the call to
    SSL_ClearSessionCache() because it is always called at shutdown, and we must
    not call it more than once.

Fixed upstream: http://www.openldap.org/its/index.cgi?findid=7022

Comment 4 Jan Vcelak 2011-08-26 11:05:40 UTC
Fixed in openldap-2.4.23-18.el6

Comment 6 Jan Vcelak 2011-08-26 13:08:16 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
- openldap-servers package is installed, TLS is enabled, multiple TLS operations are performed by clients or other replicated servers
- the server will crash with segmentation fault
- fix was applied which adds mutex to protect calling of Mozilla NSS initialization functions, which are not thread safe
- the server will no longer crash when initializing TLS because of thread races

Comment 7 Götz Reinicke 2011-09-03 11:24:05 UTC
Hi, I think, we do have the same problem, as our recent openldap-2.4.23-15.el6_1.1 dies to ...

I read a lot of bugzilla threads here and now I'm lookig for the rpm-version you mention (openldap-2.4.23-18.el6).

Where can I find that version? Thanks

Comment 8 Ondrej Vasik 2011-09-03 14:58:28 UTC
It is still under testing and therefore is not publically available. The only way is to contact RHEL product support (bugzilla is just bug tracking tool) or to wait until public beta for 6.2...

Comment 9 Götz Reinicke 2011-09-03 15:28:38 UTC
Thanks Ondrej for your answer, but I'm realy disappointed from....

As far as I can see, the problem with the latest official RH EL openladp package is more than three month old ... if you look up other bugzilla entries @ redhat. It is known for a couple of fedora openldap-releases and red hat releases a problematic update (openldap-2.4.23-15).

For us the problem with the product support is: We are an university and dont get product support or we do get it if we pay a lot extra for it. And that for such a faulty update package understandable. Neither is waiting for an update somewhen in the future....

I know you (and redhat) do have their policyies, but may be you have an other option for us?

Comment 10 Ondrej Vasik 2011-09-03 17:47:17 UTC
Ok, I understand it could be disappointing if you know that there is a package with a fix and is not available to public. If the official product support is not an option and you can't wait for official update - probably rebuilding openldap package with a fix from Fedora could work for you... or maybe Jan could offer some different way if the issue is really that critical for you... I'm sorry that we can't help you more.

Anyway - 3 months old package is not old for any enterprise software - and RHEL is not different here. RHEL has release cycle of minor releases aproximately 6-9 months and the packages released asynchronously are very limited (usually critical and security fixes).

OpenLDAP package is known to have quite a lot of issues (usually fixed within the minor release - openldap is approved component for update almost every minor release) - and some important issues escalated via support channel are even released asynchronously. I'm sure Jan is trying to have openldap as stable as possible.

To your comment about "this is known for a couple of fedora openldap releases" - Jan Vcelak is Fedora maintainer as well - and if you check the changelog - he is quite active there - and this one issue was reported in Fedora ~2 weeks ago - and the update is still ON_QA even there.

Additionally - known issue doesn't mean fixed issue - and openldap is very complex package with a lot of hard to fix bugs. This one was cloned from Fedora report by Jan - so he acted proactively to get the fix into RHEL-6 asap...

Comment 11 Jonathan Underwood 2011-09-06 01:08:51 UTC
Will this not be pushed as an update to RHEL 6.1?

Comment 12 errata-xmlrpc 2011-12-06 11:49:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1514.html


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