389-ds-base

#49246 ns-slapd crashes in role cache creation.
Closed: wontfix Opened by mreynolds.

Closed: wontfix
Reopen Issue

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1449098

Created attachment 1277312
full st.
Description of problem:
there's a directory crash while creating role cache. At first I thought it
could be "bug 1419162 A filtered nsrole that specifies an empty nsrole in its
nsRoleFilter will result in a segfault." but this bug is fixed in customer
version: 389-ds-base-1.3.5.10-20
The problem is that customer cannot give us the core file because of
confidentiality.
We see in the stack trace:
Thread 1 (Thread 0x7ff7502478c0 (LWP 6591)):
#0  0x00007ff7427c4d68 in strcmpi_fast (src=0x7ff7427c6fe3 "nsRole", dst=0x1
<Address 0x1 out of bounds>) at ldap/servers/slapd/intrinsics.h:29
        f = <optimized out>
        l = <optimized out>
#1  roles_check_filter (filter_list=0x7ff76fcbbb80) at
ldap/servers/plugins/roles/roles_cache.c:1089
        f = 0x7ff76fcbbc80
        type = 0x0
#2  roles_cache_create_object_from_entry (hint=0, result=<synthetic pointer>,
role_entry=0x7ff76fb992c0) at ldap/servers/plugins/roles/roles_cache.c:1277
        filter = 0x7ff76fcbbb80
        filter_attr_value = 0x7ff751828640 "(&(|(objectclass=govermentalapplica
tionprocess)(networkuser=app::*))(userpassword=*))"
        pb = <optimized out>
        parent = 0x0
        rc = 0
        type = <optimized out>
        this_role = 0x7ff76fc5aac0
        rolescopeDN = <optimized out>
So, we can deduce that in
static int roles_check_filter(Slapi_Filter *filter_list)
{
        Slapi_Filter  *f;
        char *type = NULL;
        for ( f = slapi_filter_list_first( filter_list );
                  f != NULL;
                  f = slapi_filter_list_next( filter_list, f ) )
        {
                slapi_filter_get_attribute_type(f, &type);
                if (strcasecmp(type, NSROLEATTR) == 0){
                        return -1;
                }
        }
        return 0;
}
while browsing the Slapi_Filter object that was built from:
"(&(|(objectclass=govermentalapplicationprocess)(networkuser=app::*))(userpassw
ord=*))"
one of the attribute types is corrupted.
I could try to ask the customer to run gdb and get more information if needed.
I will attach full pstack.
Version-Release number of selected component (if applicable):
389-ds-base-1.3.5.10-20

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1449098

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1449098

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

0001-Ticket-49246-ns-slapd-crashes-in-role-cache-creation.patch

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review
- Custom field type adjusted to defect

This code looks okay, but the risk is that because we have it as a recursive check (not an iterative one), it could cause some issues with extremely complex filters. However, given only admins can set these, I think it's low risk.

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to ack (was: review)

The crash occurs because dereferencing 'type' (0x1). 'type' is computed from slapi_filter_get_attribute_type and it fails to retrieve either objectclass, networkuser or userpassword.
I do not understand why the fix is in roles_check_filter rather than in slapi_filter_get_attribute_type.

The crash occurs because dereferencing 'type' (0x1). 'type' is computed from slapi_filter_get_attribute_type and it fails to retrieve either objectclass, networkuser or userpassword.
I do not understand why the fix is in roles_check_filter rather than in slapi_filter_get_attribute_type.

Hmmm, given @tbordaz I might download and run this with ASAN to be sure if that's okay @mreynolds ?

The crash occurs because dereferencing 'type' (0x1). 'type' is computed from slapi_filter_get_attribute_type and it fails to retrieve either objectclass, networkuser or userpassword.
I do not understand why the fix is in roles_check_filter rather than in slapi_filter_get_attribute_type.

At first glance this would appear to be the issue, but it's not! :) The problem is that the filter processing was lazy and it skipped over nested filters. When it hit a nested/complex filter it returned a NULL type (which caused the crash in this ticket). But, this is very bad if we just skip it - we need to check if its a complex filter, if so, then break it down again and continue processing each filter. So we need the recursion here to walk all the filters. So sure we can skip over NULL types, but then we also skip over all the nested filters. That allows nsrole to be allowed in the filtered role which then also crashes the server later on. Remember the point of this function to check if nsrole is somewhere in the filter, if so, it must reject it!

So the problem turned out to be a much more complicated issue than what it first appeared to be. I hope this clarifies the issue/fix.

Hmmm, given @tbordaz I might download and run this with ASAN to be sure if that's okay @mreynolds ?

Sure, please do the ASAN test, but please do it soon :) This fix needs to go into downstream builds asap.

Thanks @mreynolds for the explanations. The fix looks good and you have my ack.

Thanks @mreynolds for the explanations. The fix looks good and you have my ack.

Thanks @mreynolds for the explanations. The fix looks good and you have my ack.

c2672e7..54e4fca master -> master

4e63c2b..d1d1a79 389-ds-base-1.3.6 -> 389-ds-base-1.3.6

0ff9bb3..56961be 389-ds-base-1.3.5 -> 389-ds-base-1.3.5

b46fb65..6fee07c 389-ds-base-1.2.11 -> 389-ds-base-1.2.11

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review (was: ack)
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

You've already commited it, so I'll just build master and run the test. Will let you know how it goes.

I think there is a memory leak here:

Indirect leak of 7 byte(s) in 1 object(s) allocated from:
    #0 0x7f09a1950238 in __interceptor_strdup (/lib64/libasan.so.4+0x77238)
    #1 0x7f09a0fa460e in slapi_ch_strdup /home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:204
    #2 0x7f09a113462f in str2simple /home/william/development/389ds/ds/ldap/servers/slapd/str2filter.c:386
    #3 0x7f09a1132b4e in slapi_str2filter /home/william/development/389ds/ds/ldap/servers/slapd/str2filter.c:73
    #4 0x7f09a1132dc6 in str2list /home/william/development/389ds/ds/ldap/servers/slapd/str2filter.c:121
    #5 0x7f09a1132b1a in slapi_str2filter /home/william/development/389ds/ds/ldap/servers/slapd/str2filter.c:67
    #6 0x7f0991628d28 in roles_cache_create_object_from_entry /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:1267
    #7 0x7f0991627942 in roles_cache_create_role_under /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:1058
    #8 0x7f0991625c3c in roles_cache_update /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:618
    #9 0x7f09916257eb in roles_cache_trigger_update_role /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:560
    #10 0x7f0991626df4 in roles_cache_change_notify /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:916
    #11 0x7f099162e026 in roles_post_op /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_plugin.c:342
    #12 0x7f09a10b0f87 in plugin_call_func /home/william/development/389ds/ds/ldap/servers/slapd/plugin.c:2099
    #13 0x7f09a10b0bbb in plugin_call_list /home/william/development/389ds/ds/ldap/servers/slapd/plugin.c:2041
    #14 0x7f09a10a8c52 in plugin_call_plugins /home/william/development/389ds/ds/ldap/servers/slapd/plugin.c:452
    #15 0x7f099348ff07 in ldbm_back_add /home/william/development/389ds/ds/ldap/servers/slapd/back-ldbm/ldbm_add.c:1158
    #16 0x7f09a0f854d7 in op_shared_add /home/william/development/389ds/ds/ldap/servers/slapd/add.c:705
    #17 0x7f09a0f82a16 in do_add /home/william/development/389ds/ds/ldap/servers/slapd/add.c:229
    #18 0x423425 in connection_dispatch_operation /home/william/development/389ds/ds/ldap/servers/slapd/connection.c:618
    #19 0x429803 in connection_threadmain /home/william/development/389ds/ds/ldap/servers/slapd/connection.c:1770
    #20 0x7f099eceffca  (/lib64/libnspr4.so+0x28fca)

Sorry :(

I think there is a memory leak here:

Indirect leak of 7 byte(s) in 1 object(s) allocated from:
    #0 0x7f09a1950238 in __interceptor_strdup (/lib64/libasan.so.4+0x77238)
    #1 0x7f09a0fa460e in slapi_ch_strdup /home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:204
    #2 0x7f09a113462f in str2simple /home/william/development/389ds/ds/ldap/servers/slapd/str2filter.c:386
    #3 0x7f09a1132b4e in slapi_str2filter /home/william/development/389ds/ds/ldap/servers/slapd/str2filter.c:73
    #4 0x7f09a1132dc6 in str2list /home/william/development/389ds/ds/ldap/servers/slapd/str2filter.c:121
    #5 0x7f09a1132b1a in slapi_str2filter /home/william/development/389ds/ds/ldap/servers/slapd/str2filter.c:67
    #6 0x7f0991628d28 in roles_cache_create_object_from_entry /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:1267
    #7 0x7f0991627942 in roles_cache_create_role_under /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:1058
    #8 0x7f0991625c3c in roles_cache_update /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:618
    #9 0x7f09916257eb in roles_cache_trigger_update_role /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:560
    #10 0x7f0991626df4 in roles_cache_change_notify /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_cache.c:916
    #11 0x7f099162e026 in roles_post_op /home/william/development/389ds/ds/ldap/servers/plugins/roles/roles_plugin.c:342
    #12 0x7f09a10b0f87 in plugin_call_func /home/william/development/389ds/ds/ldap/servers/slapd/plugin.c:2099
    #13 0x7f09a10b0bbb in plugin_call_list /home/william/development/389ds/ds/ldap/servers/slapd/plugin.c:2041
    #14 0x7f09a10a8c52 in plugin_call_plugins /home/william/development/389ds/ds/ldap/servers/slapd/plugin.c:452
    #15 0x7f099348ff07 in ldbm_back_add /home/william/development/389ds/ds/ldap/servers/slapd/back-ldbm/ldbm_add.c:1158
    #16 0x7f09a0f854d7 in op_shared_add /home/william/development/389ds/ds/ldap/servers/slapd/add.c:705
    #17 0x7f09a0f82a16 in do_add /home/william/development/389ds/ds/ldap/servers/slapd/add.c:229
    #18 0x423425 in connection_dispatch_operation /home/william/development/389ds/ds/ldap/servers/slapd/connection.c:618
    #19 0x429803 in connection_threadmain /home/william/development/389ds/ds/ldap/servers/slapd/connection.c:1770
    #20 0x7f099eceffca  (/lib64/libnspr4.so+0x28fca)

Sorry :(

Actually, scrap that, I think that this is unrelated. Re-running, it passes with no leaks from this change. Sorry!

Actually, scrap that, I think that this is unrelated. Re-running, it passes with no leaks from this change. Sorry!

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

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)
Metadata
None
None
None
None
review
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.