#47519 memory leaks in access control
Closed: wontfix None Opened 10 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)

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

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)

3 years ago

Login to comment on this ticket.

Metadata