[Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument

[Jan Cholasta]

Hi,

On 14.7.2016 14:36, Stanislav Laznicka wrote:
> Hello,
>
> This patch fixes https://fedorahosted.org/freeipa/ticket/5640.
>
> With not so much experience with the framework, it raises question in my
> head whether ipaldap.get_entries is used properly throughout the system
> - does it always assume that it gets ALL the requested entries or just a
> few of those as configured by the 'ipaSearchRecordsLimit' attribute of
> ipaConfig.etc which it actually gets?

That depends. If you call get_entries() on the ldap2 plugin (which is 
usually the case in the framework), then ipaSearchRecordsLimit is used. 
If you call it on some arbitrary LDAPClient instance, the hardcoded 
default (= unlimited) is used.

>
> One spot that I know the get_entries method was definitely not used
> properly before this patch is in the
> baseldap.LDAPObject.get_memberindirect() method:
>
>  692             result = self.backend.get_entries(
>  693                 self.api.env.basedn,
>  694                 filter=filter,
>  695                 attrs_list=['member'],
>  696                 size_limit=-1, # paged search will get everything
> anyway
>  697                 paged_search=True)
>
> which to me seems kind of important if the environment size_limit is not
> set properly :) The patch does not fix the non-propagation of the
> paged_search, though.

Why do you think size_limit is not used properly here?

Anyway, this ticket is not really easily fixable without more profound 
changes. Often, multiple LDAP searches are done during command 
execution. What do you do with the size limit then? Do you pass the same 
size limit to all the searches? Do you subtract the result size from the 
size limit after each search? Do you do something else with it? ... The 
answer is that it depends on the purpose of each individual LDAP search 
(like in get_memberindirect() above, we have to do unlimited search, 
otherwise the resulting entry would be incomplete), and fixing this 
accross the whole framework is a non-trivial task.

Honza

-- 
Jan Cholasta