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

[thierry bordaz]

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