On 10/07/2014 11:43 AM, Alexander Bokovoy wrote:
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.
In idview_process_filter_cb, there is a override of an attribute name into "ipaAnchorUUID". I do not know what attribute required this override, but my concern is that depending on the order of the attributes in the filter, this override may not occur. I agree that if no existing filter is in this case it is not required to go until the end of the filter. Now if new clients starts using such filter pattern, it will also require a change in the plugin.

From the performance point of view, it requires more processing at the filter level. unless filters are very long I would not expect a significant impact.

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?
Yes that could be an accelerator, when idview_process_filter_cb() has override an attribute into "ipaAnchorUUID" a flag could be reported to backend_search_filter_has_cn_uid to decide to stop the filter processing.

To be honest I would prefer a systematic traverse of the filter until its end, even at the cost of additional processing. It would be easier to understand what the rewrite is doing and make it compatible with client enhancements.


thanks
thierry


_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to