[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