[SSSD] [PATCH] [RFC] refactor nested group processing

Pavel Březina pbrezina at redhat.com
Thu Feb 21 10:25:02 UTC 2013


On 02/18/2013 02:40 PM, Pavel Březina wrote:
> On 02/15/2013 07:42 PM, Pavel Březina wrote:
>> Happy weekend everyone,
>> if you are bored you can look at this code.
>>
>> I believe noderef path is fully completed. I haven't tried it so far,
>> it will not even compile - hopefully only because there are no function
>> prototypes. Those task are next on my schedule.
>>
>> There is one logical change that may need explaining. In the current
>> code, every group from member attribute is always pulled from LDAP. But
>> it is not further processed nor stored in hash table (and therefore in
>> sysdb) if we have reached the maximum nesting level.
>>
>> Now, if we know ahead that the dn is a group and we have reached the
>> maximum nesting level, we skip the group without contacting LDAP. That
>> brings a little change in condition level > max_level to level >=
>> max_level, because we do the check before increasing the nesting level.
>>
>> Otherwise everything should be well explained from the code or
>> comments. If not, than I have apparently failed the job.
>
> Hi,
> I tried it, fixed it and it works... at least the scenarios I have
> tried. I'm attaching also a second patch, that replaces the old code
> with the new one. I did not remove the old code yet though, it is more
> convenient for me to write deref version when the old code is present
> within the same project.
>
> My testing discovered one more problem in ghost users. The reason why we
> decided to do this refactoring is that we couldn't cope with a member
> that is outside the search bases - we waited 60 seconds for timeout.
>
> Currently we have fixed 1.9 so that it does not hang, however it breaks
> nesting. For example when we have:
>
> dn: cn=test-group-1,ou=Groups,dc=example,dc=com
> objectClass: groupOfNames
> objectClass: top
> objectClass: posixGroup
> cn: test-group-1
> gidNumber: 20001
> member: cn=user-1,ou=People,dc=example,dc=com
> member: cn=user-2,ou=People,dc=example,dc=com
> member: cn=test-group-2,ou=Groups,dc=example,dc=com
> member: cn=user-2-1,ou=People2,dc=example,dc=com
>
> user-2-1 is outside configured search bases.
>
> test-group-2 is correctly downloaded, processed and stored, but getent
> doesn't show members of test-group-2.
>
>  > getent group test-group-1
> test-group-1:*:20001:user-1,user-2
>
> test-group-1 contains only user-1 and user-2 ghost users.

This turned out to be the same issue that was already reported:
https://fedorahosted.org/sssd/ticket/1194




More information about the sssd-devel mailing list