[Date Prev][Date Next]
Re: (ITS#6463) dnssrv_back_referrals: ldaps not handled, search base gone
> Full_Name: Jochen Keutel
> Version: 2.4.21
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (126.96.36.199)
> dnssrv_back_referrals() always returns ldap URLs - even when the original
> request was a ldaps query.
This is a (logical) duplicate of ITS#6462; see related answers.
> Additionally only protocol and hostname are put into the URL - the search
> doesn't appear any more.
> Problematic code:
> url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] );
> url.bv_val = ch_malloc( url.bv_len + 1 );
> strcpy( url.bv_val, "ldap://" );
> strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] );
> I'm not sure whether you want me to deliver a complete patch or not ...
This behavior conforms to RFC4511, section 4.1.10:
- If the <dn> part is present, the client uses this name in its next
request to progress the operation, and if it is not present the
client uses the same name as in the original request.
I note that few lines above the same RFC states:
- It is RECOMMENDED that the <dn> part be present to avoid ambiguity.
However, slapd-dnssrv(5) computes the referral from DNS SRV records,
rather than returning data it knows about. So returning the <dn> part
here would be incorrect, in my opinion, as the client could legitimately
rely on the fact that the returned DN is appropriate, while it may not.