[Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree

Alexander Bokovoy abokovoy at redhat.com
Tue Oct 7 09:43:58 UTC 2014


On Tue, 07 Oct 2014, thierry bordaz wrote:
>   A question about backend_search_filter_has_cn_uid.
>   It checks if a filter components contains
>   (uid|uidNumber|gidNumber|memberUid) and in this case returns
>   SLAPI_FILTER_SCAN_STOP. This value will interrupt the filter rewriting.
>
>   In addition, for each component it calls idview_process_filter_cb to
>   override an attribute that needs to be override in the view.
>   So I wonder if it will work for filter like:
>
>   (&(<attribute_to_override>=xxx) (uid=yyy))
>
>   but will stop to early for
>
>   (&(uid=yyy)(<attribute_to_override>=xxx))
We handle the requests which come from various NSS clients here
(nss-pam-ldapd, nss_ldap, sssd, and similar). They don't do reordering
like you say.

Since all these searches never base queries on attributes other the ones
we check (uid|uidNumber|gidNumber|memberUid), we don't need to replace
other attributes here.

I can see there could be a case where we get something like (actual
query): 
  (&(gidNumber=1878600500)
    (|(objectClass=groupOfNames)
      (objectClass=posixGroup))
    (cn=*)(&(gidNumber=*)(!(gidNumber=0)))) 

and we need to ignore '*' and '0' if they come before explicit
gidNumber=<id>, I'll fix this one.

Do you think we need to traverse the filter tree until it ends in all
cases? In all filter types I've seen we are interested only in a single
name and once we've got attributes filled in, we don't need to continue.

Maybe for the replacement case of idview_process_filter_cb() we can have
some flag in the filter processing config that forces to go through the
fliter no matter what?

-- 
/ Alexander Bokovoy




More information about the Freeipa-devel mailing list