apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Date Mon, 19 Jan 2009 22:19:48 GMT
On Fri, Jan 16, 2009 at 4:07 PM, Paul J. Reder <rederpj@remulak.net> wrote:

> 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).
> I assume from reading the referenced page that 5 is not magic. No value
> works.
> 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

>  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:
> I had originally coded it to be unsupported for openldap in general (based
> on the
> 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.
>  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.)
> I know that some of the libs implement a hoplimit internally but don't
> support
> 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
> 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

View raw message