Bug 871485
| Summary: | RPM libraries cause catastrophic failure of applications using NSS for PKI | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Dennis <jdennis> |
| Component: | rpm | Assignee: | Fedora Packaging Toolset Team <packaging-team> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 17 | CC: | ffesti, fweimer, herrold, jnovy, jzeleny, packaging-team, pknirsch, pmatilai, tmraz |
| Target Milestone: | --- | Keywords: | Upstream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-05-20 11:18:36 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Right, the NSS_*Context() variants didn't exist back when rpm switched to NSS crypto and I haven't been paying that much attention to what happens in that world except when somebody reports problems - this is the first time this particular issue has been reported. Anyway, seems like a straightforward thing to fix and perhaps even make the NSS init/shutdown that little bit less painful to rpm. Fixed upstream: http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=5ecfdcea4e80e58f133ffddd69130ee8df28b2ac This is supposed to be fixed in rawhide now (rpm >= 4.10.90), so if you have an easy way to reproduce it, testing wouldn't hurt. This has been fixed in Fedora >= 18, backporting to F17 doesn't seem worth the trouble at this point. |
This problem showed up using the python binding to RPM but I suspect the problem is generic to any process linking to the RPM libraries. The RPM library will initialize NSS without a database thus preventing any application linking against RPM from using NSS with a database, a catastrophic failure for the application because it will be unable to access PKI resources. Here is a stack trace from a Python application in which the RPM module was loaded. #1 0xb77b5200 in NSS_NoDB_Init (configdir=configdir@entry=0x0) at nssinit.c:909 #2 0xb78f7477 in rpmInitCrypto () at rpmpgp.c:1642 #3 0xb7b26910 in rpmReadConfigFiles (file=file@entry=0x0, target=target@entry=0x0) at rpmrc.c:1772 #4 0xb7fcee7c in initModule (m=<module at remote 0x80d3be4>) at rpmmodule.c:280 #5 init_rpm () at rpmmodule.c:264 As you can see rpmInitCrypto() calls NSS_NoDB_Init(). This happens before the application has the opportunity to initialize NSS with it's desired database. Once NSS has been initialized subsequent calls to initialize NSS are ignored. This causes catastrophic failure for the application because it is being denied access to it's PKI resources (because rpmInitCrypto declared PKI resources should be disabled) The following document fully explains the issue and the solution: https://wiki.mozilla.org/NSS_Library_Init In particular pay attention to Scenario 2, this is the issue at hand. In essence it means calling NSS_InitContext() instead of NSS_NoDB_Init() and NSS_ShutdownContext() instead of NSS_Shutdown().