Sponsored development rlm_ldap and ocsp

[John Dennis]

On 08/27/2010 06:48 AM, Stephan Jäger wrote:
> Am 20.08.2010 18:43, schrieb John Dennis:
>> Attached is a git format patch which adds support for storing clients in
>> LDAP. The necessary schema can be found in
>> doc/examples/389_ds_schema.ldif. This is schema ldif file suitable for
>> use with 389-ds (the standard LDAP server shipped with Fedora and RHEL
>> which over the years with different versions has been known under a
>> variety of names, Netscape Directory Server, iPlanet, Sun Directory
>> Server, Red Hat Directory Server, Fedora Directory server).
>
> There seems to be a problem if you have more than one client in LDAP.
>
> perform_search() says:
>
> DEBUG(" [%s] got ambiguous search result (%d results)", inst->xlat_name,
> ldap_errno);
>
> clears the result and returns with RLM_MODULE_NOTFOUND if you have 0 or
>> 1 entries in the result set.
>
> Not sure what the consequences are if you just remove the>1 entries in
> the result set check in perform_search...

The callers of perform_search normally expect exactly one result because 
they are trying to find a specific entry. However that logic is really 
in the domain of the routine calling perform_search because only they 
know what they're looking for and the logic surrounding it. The search 
routine should just perform a search and not impose logic of it's own on 
the result. I imagine the reason why the search routine is enforcing the 
single result condition is because previously it was always the case 1 
result was desired and it was easier to put the check in one place 
instead of after each call to perform_search.

In our case we really do want multiple results, it's wrong for 
perform_search to tell us we don't know what we're looking for, it's job 
should be to do the search, period.

There are two ways we can fix this.

1) We can add an extra parameter to perform_search which states how many 
results are expected, -1 would mean unbounded. This would eliminate 
needing to check the count every place perform_search was called.

2) We could remove the check from perform search and do the check after 
each call to perform search.

I think option 1 would be cleaner. FWIW we really do want to perform the 
check for most callers of perform_search they do need to validate the count.

I'll update the patch using option 1.

Thanks for discovering this, as I said it was only lightly tested and I 
foolishly tested only with 1 client.

John


-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/