On Fri, Jan 16, 2009 at 4:07 PM, Paul J. Reder <firstname.lastname@example.org>
I assume from reading the referenced page that 5 is not magic. No value works.
Jeff Trawick wrote:
With Ubuntu's packaging of OpenLDAP 2.4.9 and whatever OpenLDAP is in Leopard.latest, LDAP_OPT_REFHOPLIMIT is defined in ldap.h but the library returns an error when trying to set it to 5 (httpd LDAP's default value). This is apparently a wide-spread issue (http://article.gmane.org/gmane.network.openldap.devel/3619).
What error is returned? Is it an error that clearly indicates the option isn't
supported or does it specify something nebulous like "a bad parm was passed"?
Hop limits 0, 1, and 2 failed as well. The return code is just LDAP_OPT_ERR, which doesn't sound very specific. (Given the simple nature of this LDAP option, it may be reasonable to assume that LDAP_OPT_ERR means not-implemented.)
I had originally coded it to be unsupported for openldap in general (based on the
The intent in apr_ldap_set_option() is apparently to ignore lack of support for LDAP_OPT_REFHOPLIMIT, but that is implemented with this compile-time check:
#if !defined(LDAP_OPT_REFHOPLIMIT) || APR_HAS_NOVELL_LDAPSDK
latest openldap doc at the time). It was later changed to look specifically for
LDAP_OPT_REFHOPLIMIT, and then again later to add the check for NOVELL.
I know that some of the libs implement a hoplimit internally but don't support
How to handle... Ignore failures and return success if LDAP_OPT_REFHOPLIMIT defined but the set fails?
(As an aside, this busts httpd trunk's LDAP auth with these libraries until you set LDAPReferrals Off.)
changing it with ldap_set_option. My concern would be for cases, if any, where the
limit is just plain not implemented (I don't know if such a lib exists). If there
is any chance the limit wouldn't be changeable *or* enforced in any form then I
would definitely say if an error is returned, log something and turn referrals off.
The difficulty is in the fact that the apr_ldap_set_option code can't reset the
Apache LDAPReferrals value. Soooo...
APR should return success, a meaningful error code, or possibly APR_ENOTIMPL based
on the best config/compile-time checks we can come up with, then falling back on
our best understanding/interpretation of native lib return codes.
Then the Apache portion of the code should handle the apr return values. Logging
and turning LDAPReferrals off if necessary.
In the app, why not let the option to enable/disable referrals be the only crucial aspect (setup fails if that option fails), and not fail connection setup if we can't specify the hop limit (assume that the LDAP client library does the right thing)?
Note that currently none of the other options in the apr_ldap_set_option code
return APR_ENOTIMPL however.
Paul J. Reder
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein