#47958 Memory leak in password admin if the admin entry does not exist
Closed: wontfix None Opened 6 years ago by mreynolds.

If the entry defined for passwordAdminDN does not exist memory is leaked:

==5617== 8 bytes in 1 blocks are definitely lost in loss record 136 of 1,958
==5617==    at 0x4C291D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5617==    by 0x4E85656: slapi_ch_calloc (ch_malloc.c:243)
==5617==    by 0x4EEF450: search_internal_pb (plugin_internal_op.c:671)
==5617==    by 0x4EEF1E0: slapi_search_internal_pb (plugin_internal_op.c:574)
==5617==    by 0x4EF86E5: pw_get_admin_users (pw.c:1563)
==5617==    by 0x4EF9814: new_passwdPolicy (pw.c:1955)
==5617==    by 0x4ED2E8F: op_shared_allow_pw_change (modify.c:1240)
==5617==    by 0x4ED0C4D: do_modify (modify.c:375)
==5617==    by 0x4161FE: connection_dispatch_operation (connection.c:660)
==5617==    by 0x418166: connection_threadmain (connection.c:2534)
==5617==    by 0x718FE3A: ??? (in /usr/lib64/libnspr4.so)
==5617==    by 0x77CEEE4: start_thread (in /usr/lib64/libpthread-2.18.so)
==5617==    by 0x7AD8B8C: clone (in /usr/lib64/libc-2.18.so)
==5617==
==5617== 16 bytes in 2 blocks are definitely lost in loss record 405 of 1,958
==5617==    at 0x4C291D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5617==    by 0x4E85656: slapi_ch_calloc (ch_malloc.c:243)
==5617==    by 0x4EEF450: search_internal_pb (plugin_internal_op.c:671)
==5617==    by 0x4EEF1E0: slapi_search_internal_pb (plugin_internal_op.c:574)
==5617==    by 0x4EF86E5: pw_get_admin_users (pw.c:1563)
==5617==    by 0x4EF9814: new_passwdPolicy (pw.c:1955)
==5617==    by 0x4EF9FB1: slapi_check_account_lock (pw.c:2203)
==5617==    by 0x411618: do_bind (bind.c:732)
==5617==    by 0x416154: connection_dispatch_operation (connection.c:635)
==5617==    by 0x418166: connection_threadmain (connection.c:2534)
==5617==    by 0x718FE3A: ??? (in /usr/lib64/libnspr4.so)
==5617==    by 0x77CEEE4: start_thread (in /usr/lib64/libpthread-2.18.so)
==5617==    by 0x7AD8B8C: clone (in /usr/lib64/libc-2.18.so)

ack

If this is a SCOPE_BASE level search, why do you need a search filter?

Replying to [comment:2 rmeggins]:

ack

If this is a SCOPE_BASE level search, why do you need a search filter?

We need to verify if the base dn(aka passwordAdminDN) is a group or not. We use the filter to do this. If it's not a group, no entries returned, and the dn is considered a single user entry. Otherwise it's a group, and we need to gather its members.

c6e1074..6ee9a1b master -> master
commit 6ee9a1b
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Nov 17 09:46:33 2014 -0500

99bace9..ce0cda2 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit ce0cda2

f7fcb52..0d6f6ca 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 0d6f6ca

65d455f..972396d 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit 972396da9cf92d67e5ff597854d62c089b93ae9d

4fb2902..d9274e2 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit d9274e2

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.11.33

3 years ago

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/1289

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

4 months ago

Login to comment on this ticket.

Metadata