Hide Forgot
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.
I forgot to mention to also unbind the LDAPS connection in the steps to reproduce. Please consider it step 2b.
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.
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.
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.
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