Bug 1377413

Summary: NSS can't shut down after using LDAPS connection
Product: Red Hat Enterprise Linux 7 Reporter: Tomas Krizek <tkrizek>
Component: openldapAssignee: Matus Honek <mhonek>
Status: CLOSED ERRATA QA Contact: Dalibor Pospíšil <dapospis>
Severity: high Docs Contact:
Priority: high    
Version: 7.4CC: dapospis, mhonek, mkolaja, nkinder, pkis, pvoborni, tscherf
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openldap-2.4.44-10.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 18:16:19 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:
Attachments:
Description Flags
Reproducer none

Description Tomas Krizek 2016-09-19 15:37:42 UTC 
Description of problem: It is not possible to shut down NSS database after binding and unbinding from secure LDAP.


Version-Release number of selected component (if applicable): openldap-2.4.44-2.fc24.x86_64


How reproducible: always


Steps to Reproduce:
1. initialize NSS database
2. initialize and bind to LDAPS
3. shutdown NSS database

Actual results: nss.error.NSPRError: (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.

Expected results: NSS database is shut down


Additional info: The problem seems to be with the module that is initiated in tls_m.c. Perhaps it is not closed properly when all LDAP connections are unbounded.
Comment 2 Tomas Krizek 2016-09-19 15:43:57 UTC 
I forgot to mention to also unbind the LDAPS connection in the steps to reproduce. Please consider it step 2b.
Comment 4 Matus Honek 2016-11-16 16:25:50 UTC 
Previously I thought the issue is in NSS itself but this does not seem to be the case. Two points here:
1. The libldap's callback on NSS tries to unload the pem_module (using SECMOD_UnloadUserModule, then SECMOD_DestroyModule) which does not succeed due to an NSS slot for a PEM key which has refCount set to 2.
2. Calling ldap_unbind_ext should do the entire unloading correctly but the libldap's internal tc_tls_ctx->refCount is set to 2, too, leaving the context intact. Which seems correct but I'll have to investigate this.

It seems a fix for letting NSS_Shutdown finish successfully might be to call tlsm_free_pem_objs() in the callback. However, I have not tried it, yet, and it might also break something. I'll give it a try ASAP.

Finally, there is a more general question whether a try to unload an NSS' context common to libldap, too, should tear down the libldap with it which might be in-between operations.
Comment 13 Red Hat Bugzilla Rules Engine 2017-07-19 13:10:22 UTC 
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Comment 16 Matus Honek 2018-01-10 11:50:36 UTC 
Created attachment 1379484 [details]
Reproducer

Attaching the reproducer mentioned in the comment 1. The bug seems to be fixed with the switch to OpenSSL (bug 1400578). Anyway, we should probably have a test for this issue.
Comment 21 errata-xmlrpc 2018-04-10 18:16:19 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.

https://access.redhat.com/errata/RHEA-2018:0974