Bug 995969 - Failure of rpmReadConfigFiles() api.
Failure of rpmReadConfigFiles() api.
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
5.8
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: packaging-team-maint
BaseOS QE Security Team
:
Depends On:
Blocks: 883145
  Show dependency treegraph
 
Reported: 2013-08-12 01:25 EDT by Satya Shendige
Modified: 2013-12-17 08:12 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-17 08:12:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Satya Shendige 2013-08-12 01:25:48 EDT
Description of problem:
One of the modules of Serviceguard product uses the rpm library to extract product information and determine if the product is installed. As a part of this query rpmReadConfigFiles(NULL, NULL) is invoked to initialize the database. rpmReadConfigFiles() fails/returns a non-zero value. 

This RPM library call initializes the NSS(Network Security Services) as part of cryptography initialization.  It has been observed that NSS initialization is failing [NSS_NoDB_Init() returning -1] whenever CIMserver (pegasus) reloads the provider module. 

Analysis:   
After initialization of any provider by CIMServer, the first call to rpmInitCrypto () will initialize the NSS. And after reloading the provider, either it shouldn’t call NSS_NoDB_Init () to re-initialize NSS or it should first free up current initialization (rpmFreeCrypto()) before making a call to NNS_NoDB_Init(). We are suspecting that the above mentioned case is not perfectly handled inside RPM or NSS libs.


Version-Release number of selected component (if applicable):
Defect is seen on RHEL 5.8 and 5.9. Not reproducible on RHEL 6.2, 6.3 and 6.4

How reproducible:
Not always.

Steps to Reproduce:
1.Load/Initialize a cimprovider. Make Provider call rpmReadConfigFiles() as a part of initialization to get the path of the db.
2. Unload the cimprovider.
3. Reload the provider. When rpmReadConfigFiles() is again called it fails.
Actual results:
rpmReadConfigFiles() fails with a non-zero return value.

Expected results:
rpmReadConfigFiles() should pass with zero return value.

Additional info:
Stack Trace
#0  0x00002aaaae0ef030 in SECMOD_CreateModule () from /usr/lib64/libnss3.so   
 #1  0x00002aaaae0ef8a8 in SECMOD_LoadModule () from /usr/lib64/libnss3.so
#2  0x00002aaaae0c06e1 in ?? () from /usr/lib64/libnss3.so
#3  0x00002aaaae0c0c97 in NSS_NoDB_Init () from /usr/lib64/libnss3.so     
 #4  0x00002aaaace381e8 in rpmInitCrypto () from /usr/lib64/librpmio-4.4.so
#5  0x00002aaaac3111a1 in rpmReadConfigFiles () from /usr/lib64/librpm-4.4.so
#6  0x00002aaaab960007 in Class_name::cimprovider_construct (this=0x2b9f35dfe100, userName=...)

rpmReadConfigFiles should call rpmFreeCrypto()  before calling rpmInitCrypto() during reload.


Description: 

Packages to be added: 

Comps group:  

Default: 

Mandatory: 

Visible: 

Multi-lib: 

Need to be present for arches: 


Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Panu Matilainen 2013-08-12 01:51:49 EDT
redhat-rpm-config is mere configuration data, actual functionality is in rpm itself -> switching component.

The issue is likely to be the two components fighting over global NSS context, which was the only possibility back when rpm started using NSS. These days (since version 3.2.15) NSS supports private contexts which can be used to fix the issue in either involved component, and newer rpm versions take advantage of this already (see bug 871485).

Whether this qualifies as critical enough to considering fixing in rhel-5 at this point is an entirely different question however.
Comment 2 Florian Festi 2013-12-17 08:12:39 EST
We are currently not planning to port the enhancement mentioned in comment #1 back to RHEL 5. Please escalate the issue through your support contact in case this is important for you. But be aware that the over all number of packages and bugs that can be addressed in the update are limited and this issue might be seen as an RFE which have very little chances of being accepted.

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