#47519 memory leaks in access control
Closed: Fixed None Opened 6 years ago by lkrispen.

There are several memory leaks reported by valgrind in access control evaluation:

==6882== 4 bytes in 1 blocks are definitely lost in loss record 17 of 1,532
==6882== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==6882== by 0x390AE853F1: strdup (in /usr/lib64/libc-2.15.so)
==6882== by 0x4C5FD87: slapi_ch_strdup (ch_malloc.c:277)
==6882== by 0x800AAEB: acl__get_attrEval (acl.c:3930)
==6882== by 0x80051E2: acl_access_allowed (acl.c:500)
==6882== by 0x801F736: acl_access_allowed_main (aclplugin.c:383)
==6882== by 0x4CBD5C5: plugin_call_acl_plugin (plugin_acl.c:90)
==6882== by 0x4CBDA98: slapi_access_allowed (plugin_acl.c:237)
==6882== by 0x8EB28B3: sync_feature_allowed (sync_refresh.c:67)
==6882== by 0x8EB29A3: sync_srch_refresh_pre_search (sync_refresh.c:106)
==6882== by 0x4CB9D96: plugin_call_func (plugin.c:1467)
==6882== by 0x4CB9C56: plugin_call_list (plugin.c:1429)

==6882== 12 bytes in 1 blocks are definitely lost in loss record 127 of 1,532
==6882== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==6882== by 0x390AE853F1: strdup (in /usr/lib64/libc-2.15.so)
==6882== by 0x4C5FD87: slapi_ch_strdup (ch_malloc.c:277)
==6882== by 0x800A3EF: acl_copyEval_context (acl.c:3717)
==6882== by 0x800514C: acl_access_allowed (acl.c:478)
==6882== by 0x801F736: acl_access_allowed_main (aclplugin.c:383)
==6882== by 0x4CBD5C5: plugin_call_acl_plugin (plugin_acl.c:90)
==6882== by 0x4C82C67: test_filter_access (filterentry.c:1014)
==6882== by 0x4C82865: slapi_vattr_filter_test_ext_internal (filterentry.c:929)
==6882== by 0x4C82484: slapi_vattr_filter_test_ext (filterentry.c:842)
==6882== by 0x4C823BB: slapi_vattr_filter_test (filterentry.c:790)
==6882== by 0x8EB3283: sync_is_entry_in_scope (sync_refresh.c:415

==6882== 31 bytes in 1 blocks are definitely lost in loss record 347 of 1,532
==6882== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==6882== by 0x390AE853F1: strdup (in /usr/lib64/libc-2.15.so)
==6882== by 0x4C5FD87: slapi_ch_strdup (ch_malloc.c:277)
==6882== by 0x801A891: acllist_init_scan (acllist.c:637)
==6882== by 0x801F1EA: aclplugin_preop_search (aclplugin.c:167)
==6882== by 0x4CB9D96: plugin_call_func (plugin.c:1467)
==6882== by 0x4CB9C56: plugin_call_list (plugin.c:1429)
==6882== by 0x4CB7F8F: plugin_call_plugins (plugin.c:403)
==6882== by 0x4CAC986: op_shared_search (opshared.c:565)
==6882== by 0x42F30F: do_search (search.c:413)
==6882== by 0x41514C: connection_dispatch_operation (connection.c:677)
==6882== by 0x416CD8: connection_threadmain (connection.c:2482)

and a couple of leaks in
==6882== by 0x80111BA: aclinit_main (aclinit.c:130)
but this is only in init and not properly cleaned at shutdown (which is the case for many plugins)


Can you provide the aci's that are causing these leaks? Or are they just the default aci's?

no special acis for the database, there was one specific for the Sync control:

dn: oid=1.3.6.1.4.1.4203.1.9.1.1,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid: 1.3.6.1.4.1.4203.1.9.1.1
cn: Sync Request Control
aci: (targetattr != "aci")(version 3.0; acl "Sync Request Control"; allow( rea
d, search ) userdn = "ldap:///all";)

you could enable this feature, but VLV has the same aci, so this could also work

I can not reproduce any leaks. Are there any special steps I need to follow?

The fixes look ok, assuming the things that are now freed were initialized to NULL or set to a malloced value.
{{{
dest->acle_numof_attrs = d_slot;
dest->acle_attrEval[d_slot].attrEval_name = NULL;
}}}
Is it possible at this point in the code that dest->acle_attrEval[d_slot].attrEval_name is set? If so, it would need to be freed or it will be overwritten.

Replying to [comment:7 rmeggins]:

The fixes look ok, assuming the things that are now freed were initialized to NULL or set to a malloced value.
{{{
dest->acle_numof_attrs = d_slot;
dest->acle_attrEval[d_slot].attrEval_name = NULL;
}}}
Is it possible at this point in the code that dest->acle_attrEval[d_slot].attrEval_name is set?
If so, it would need to be freed or it will be overwritten.

These structures are all calloced when initialized, and also I applied your suggestion. New patch attached.

git merge ticket47519
Updating 04b6137..85bc265
Fast-forward
ldap/servers/plugins/acl/acl.c | 6 +++---
ldap/servers/plugins/acl/acl_ext.c | 3 +--
ldap/servers/plugins/acl/acllist.c | 5 +++--
3 files changed, 7 insertions(+), 7 deletions(-)

git push origin master
Counting objects: 17, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 1.02 KiB, done.
Total 9 (delta 7), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
04b6137..85bc265 master -> master

commit 85bc265
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Oct 15 16:42:25 2013 -0400

Metadata Update from @lkrispen:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.3 - 10/13 (October)

3 years ago

Login to comment on this ticket.

Metadata