Sponsored development rlm_ldap and ocsp
jdennis at redhat.com
Fri Aug 27 17:16:20 CEST 2010
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,
> 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 Dennis <jdennis at redhat.com>
Looking to carve out IT costs?
More information about the Freeradius-Devel