When a search evaluates an shadowAccount entry (to return it or not), it adds the shadow attributes (shadowMax, shadowMin....) to the entry. With fine grained password policy (nsslapd-pwpolicy-local: on), it tries to retrieve the shadow attribute from a pwdpolicysubentry.
The problem is that it retrieves pwdpolicysubentry attribute value using an internal base search of the evaluated entry. It is useless as in such case we already have the entry.
a stack could look like this
#6 0x00007f2ce7aedc27 in ldbm_back_search () at /usr/lib64/dirsrv/plugins/libback-ldbm.so #7 0x00007f2cf3fe59c2 in op_shared_search () at /usr/lib64/dirsrv/libslapd.so.0 #8 0x00007f2cf3ff7527 in search_internal_callback_pb () at /usr/lib64/dirsrv/libslapd.so.0 #9 0x00007f2cf3ff7778 in search_internal_pb () at /usr/lib64/dirsrv/libslapd.so.0 #10 0x00007f2cf3ff7b25 in slapi_search_internal_get_entry () at /usr/lib64/dirsrv/libslapd.so.0 #11 0x00007f2cf40017ff in get_entry () at /usr/lib64/dirsrv/libslapd.so.0 #12 0x00007f2cf3ffd1d6 in new_passwdPolicy () at /usr/lib64/dirsrv/libslapd.so.0 #13 0x00007f2cf40012bd in add_shadow_ext_password_attrs () at /usr/lib64/dirsrv/libslapd.so.0 #14 0x00007f2cf3fe413e in send_results_ext.constprop.4 () at /usr/lib64/dirsrv/libslapd.so.0 #15 0x00007f2cf3fe60f1 in op_shared_search () at /usr/lib64/dirsrv/libslapd.so.0 #16 0x0000564ae8ec844e in do_search () #17 0x0000564ae8eb6535 in connection_threadmain () #18 0x00007f2cf1db0bab in _pt_root () at /lib64/libnspr4.so #19 0x00007f2cf1750dd5 in start_thread () at /lib64/libpthread.so.0 #20 0x00007f2cf0dfdb3d in clone () at /lib64/libc.so.6
All versions
1.Create an instance 2.Create a shadowAccount entry 3.Enable internal search logging (nsslapd-accesslog-leve: 260) 4. Enable nsslapd-pwpolicy-local: 1 5. Do a base search on the entry and check that it exists an additional internal search on the entry
In some rsearch rate it can increase throughput by 3 times
Metadata Update from @tbordaz: - Issue assigned to tbordaz
Metadata Update from @mreynolds: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None - Issue set to the milestone: 1.3.8
05587ed -> master 42ab464..d5bc4cf 389-ds-base-1.3.8 -> 389-ds-base-1.3.8
Metadata Update from @tbordaz: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @gparente: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1593807
063455b..d3cf9f2 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
I'm concerned there could be a memory leak here. Previously if e != null, we free the entry, but now we add a flag to determine if we need to conduct the free.
It could be easier to etiher duplicate the entry (to always free it when e != NULL), because at the moment I don't see where we set free_e when e != NULL on the other branches in the function.
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2801
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.