Bug 1454611

The version in this ticket says rhel 6.6

Is it really a bug in sssd on rhel6.6?

Please provide exact version of sssd
   rpm -q sssd sssd-common

BTW I do not want to say it is not a bug. Because I briefly checked the code
and on other places we use " .. >= value_of(SDAP_NESTING_LEVEL)" or " ... != 0 value_of(SDAP_NESTING_LEVEL)"

I just would like to clarify whether customer want to fix it in latest rhel6 or in 6.6

(In reply to Lukas Slebodnik from comment #4)
> BTW I do not want to say it is not a bug. Because I briefly checked the code
> and on other places we use " .. >= value_of(SDAP_NESTING_LEVEL)" or " ... !=
> 0 value_of(SDAP_NESTING_LEVEL)"
> 
> I just would like to clarify whether customer want to fix it in latest rhel6
> or in 6.6

Yes, this was noticed by Justin during the case triage. So if anyone was going to work on this bug, please first check with Justin if he maybe already started.

/*duplication first comment edited*/

Description of problem:

What problem/issue/behavior are you having trouble with?  What do you expect to see?


SSSD looks for parents of nested groups ignoring

    ignore_group_members = True
    ldap_group_nesting_level = 0


From the logs:  

 - the first request triggers the SSSD backend at 17:25:28

(Thu May 18 17:25:58 2017) [sssd[be[DOMAIN.COM]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=username]

- The last messages in the log are only 2 seconds later, looks like the id command completed.

(Thu May 18 17:26:00 2017) [sssd[be[DOMAIN.COM]]] [dp_req_done] (0x0400): DP Request [Account #47]: Request handler finished [0]: Success
(Thu May 18 17:26:00 2017) [sssd[be[DOMAIN.COM]]] [_dp_req_recv] (0x0400): DP Request [Account #47]: Receiving request data.
(Thu May 18 17:26:00 2017) [sssd[be[DOMAIN.COM]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #47]: Finished. Success.
(Thu May 18 17:26:00 2017) [sssd[be[DOMAIN.COM]]] [dp_req_reply_std] (0x1000): DP Request [Account #47]: Returning [Success]: 0,0,Success
(Thu May 18 17:26:00 2017) [sssd[be[DOMAIN.COM]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:2:1::DOMAIN.COM:idnumber=14011] from reply table
(Thu May 18 17:26:00 2017) [sssd[be[DOMAIN.COM]]] [dp_req_destructor] (0x0400): DP Request [Account #47]: Request removed.
(Thu May 18 17:26:00 2017) [sssd[be[DOMAIN.COM]]] [dp_req_destructor] (0x0400): Number of active DP request: 0
(Thu May 18 17:26:00 2017) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: sh[0x7f17bfdbe570], connected[1], ops[(nil)], ldap[0x7f17bfdb3d20]
(Thu May 18 17:26:00 2017) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list

- However, regarding these messages - I don't really see why we are searching for parent groups of these 43 groups

(Thu May 18 17:25:58 2017) [sssd[be[DOMAIN.COM]]] [sdap_initgr_rfc2307bis_process] (0x1000): Found 43 parent groups for user [username]]
(Thu May 18 17:25:58 2017) [sssd[be[DOMAIN.COM]]] [rfc2307bis_nested_groups_send] (0x2000): About to process 43 groups in nesting level 0
(Thu May 18 17:25:58 2017) [sssd[be[DOMAIN.COM]]] [sdap_get_primary_name] (0x0400): Processing object someobject
(Thu May 18 17:25:58 2017) [sssd[be[DOMAIN.COM]]] [rfc2307bis_nested_groups_step] (0x1000): Processing group [somegroup]
(Thu May 18 17:25:58 2017) [sssd[be[DOMAIN.COM]]] [rfc2307bis_nested_groups_next_base] (0x0400): Searching for parent groups of group [CN=somename,OU=SOME,OU=SomeApplications,OU=Groups,OU=Groups,OU=Unix,OU=IAM-Technical,DC=DOMAIN,DC=COM] with base [OU=Groups,OU=Groups,OU=Unix,OU=IAM-Technical,DC=domain,DC=com]

- In the code, the first time this function gets called nesting is set to 0 which causes us to fail the condition 'nesting > ldap_nesting_level' option set to 0 in sssd.conf. There may be some reason for this behaviour that I'm not aware of.

struct tevent_req *rfc2307bis_nested_groups_send(
        TALLOC_CTX *mem_ctx, struct tevent_context *ev,
        struct sdap_options *opts, struct sysdb_ctx *sysdb,
        struct sss_domain_info *dom, struct sdap_handle *sh,
        struct sdap_search_base **search_bases,
        struct sysdb_attrs **groups, size_t num_groups,
        hash_table_t *group_hash, size_t nesting)
{
    errno_t ret;
    struct tevent_req *req;
    struct sdap_rfc2307bis_nested_ctx *state;

    DEBUG(SSSDBG_TRACE_INTERNAL,
          "About to process %zu groups in nesting level %zu\n",
           num_groups, nesting);

    req = tevent_req_create(mem_ctx, &state,
                            struct sdap_rfc2307bis_nested_ctx);
    if (!req) return NULL;

    if ((num_groups == 0) ||
        (nesting > dp_opt_get_int(opts->basic, SDAP_NESTING_LEVEL))) {          <------------- 0 is not > 0 
        /* No parent groups to process or too deep*/
        ret = EOK;
        goto done;
    }

The case is reported for 6.6, but should be the case for other versions too.

Hello,

Customer is asking for 6.6 fix (if it is possible)


Andrey

(In reply to Andrey Bondarenko from comment #8)
> Hello,
> 
> Customer is asking for 6.6 fix (if it is possible)
> 
> 
> Andrey

I'm sorry, but if I understand the bug correctly, it "only" affects performance. If that's correct, then fixing the bug is borderline even for 6.10 and it's definitely not going to happen in 6.6.

RHEL-6 in general is only open to High and Urgent bugs at the moment.

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3425

 * master:
   * 6d57cd501c28aa52731c56cd751bbc404f991ae0
   * 925a14d50edf0e3b800ce659b10b771ae1cde293

Since the customer case was closed, the original patches linked from comment #17 were causing issues and were reverted upstream and in general this seems to be out of scope of RHEL-6, I'm closing the bug as WONTFIX.