[SSSD] [PATCHES][PRELIMINARY] ldap_*_search_base doesn't fully limit the group / netgroup

Pavel Březina pbrezina at redhat.com
Wed Nov 23 16:20:31 UTC 2011


Dne 22.11.2011 14:14, Pavel Březina napsal(a):

> There is probably one bug, when you have several search bases when one
> is a generalization of the other but with more restrictive filter.
>
> For example (LDIF attached):
> ldap_group_search_base =
> cn=QA,ou=Groups,dc=brq,dc=redhat,dc=com?sub??
> cn=DEV,ou=Groups,dc=brq,dc=redhat,dc=com?sub?
>
> ldap_user_search_base =
> cn=NewHires,ou=People,dc=brq,dc=redhat,dc=com?sub?? (A)
> ou=People,dc=brq,dc=redhat,dc=com?sub?(&(uid=u1)(uid=u5)) (B)
>
> GroupA (direct or indirect) members in LDIF are:
> u1, u3 (from B), u4 (from A)
>
> Expected result might be u4 (it is currently the actual result).
> However, B is a contradiction and the filter contains this
> contradiction*) so the actual result should be empty membership. But the
> result is:
> getent group groupA
> groupA:*:10002:u4
>
> * calling ldap_search_ext with
> [(&(|(&(uid=u1)(uid=u3)))(objectclass=posixAccount))][cn=u4,cn=NewHires,ou=People,dc=brq,dc=redhat,dc=com]
>
>
> Does anyone know what am I missing?

With Jan's help we've managed to localize the problem. The behaviour 
depends on enumerate option. If enumeration is disabled, it returns an 
empty result. If enabled, the result is u4. I'll work on a fix.

Thank you Jan.



More information about the sssd-devel mailing list