Re: (ITS#5339) wrong referral from back-bdb

[hyc@symas.com]

Hallvard B Furuseth wrote:
> Howard Chu writes:
>> h.b.furuseth@usit.uio.no wrote:
>>> Howard Chu writes:
>>>>> Both RFCs disagree.
>>>> They are wrong. Or at least, under-specified. In X.501 section 17.3
>>>> "Directory Distribution Model" it's quite clear that all of the
>>>> components of a distributed directory must belong to a single DIT.
>>> Which is not true in the LDAP world, and I don't know about today's
>>> X.500 world.  Nameflow died and Dante was unable to resurrect it.  Maybe
>>> the X.500 world has also switched to 'dc' structure, I don't know.
>>>
>>> Anyway, LDAP is not X.500.
>> RFC4510 Section 2 "Relationship to X.500"
>>      (...) An LDAP server MUST act in accordance with the X.500 (1993)
>>      series (...)
>
> Except when it doesn't.  Like the various implications of sending text
> instead of ASN.1 and numeric OIDs.

That's irrelevant. The service model and the on-the-wire encoding are two 
completely different things. The encoding of LDAP is of course different from 
DAP, but both are required to provide the same service model. Just as DSML is 
encoded differently, but still delivers the X.500 service model.

>> (...)  LDAPv1 had no referrals. When they were introduced in LDAPv2
>> it's clear that nobody knew what they were doing, or nobody wanted to
>> tackle the glaring absence of an analogue to X.500 DSP.

> LDAPv2 (the standard) has no referrals.  The Umich implementation
> introduced them as a hack: It stuffed them into the errorMessage field.
> LDAPv3 moved them into the standard.  And speaking for my own little
> corner of the standardization process, I definitly was ignorant about
> them and wanted nothing to do with them.  I've still never had any use
> for LDAP referrals.
>
>> They should never have been introduced.  We're stuck with them for
>> now, but we can at least try to make them make sense.
>
> Well, take it up with ldapext.  And add an option to slapd to reject
> attempts to add 'ref' attrs with a DN, or whatever.
>
> For now, once the directory contains a 'ref' URL which includes the DN,
> I don't see any reason not to rewrite like the spec says.  Whatever the
> "right answer" is, a referral with an un-rewritten DN seems worse than
> with a rewritten one.

> Regarding the branches of bdb_referrals() and ldif_back_referrals()
> which rewrite default_referral: I suggest we delete it.
> The back-ldif code breaks exactly as one would expect:  With
>      referral ldap://urgle/
>      database ldif
>      suffix   o=foo
> and an empty database, ldapcompare cn=bar,o=foo gives a referral to
> urgle.  So does ldapadd of o=foo:-(  I seem to remember someone meant
> the latter was correct and there was a control to prevent it at some
> point, maybe that is related.  back-bdb has a test which prevents this
> referral in case of the suffix dn, but not for superior DNs.  But I
> don't see why it would not be just as buggy for superiors, if it could
> happen.

Yeah, I noticed that in the source recently and thought that was bogus. The 
default referral was only supposed to be used when fielding a query for a 
completely unknown naming context. However, e.g. back-bdb tries to use the 
default referral whenever a requested entry does not exist, and leaves it to 
the frontend to turn that result back into NoSuchObject as appropriate.

For cases where the context is known, but no data is present, it should just 
return NoSuchObject. Sending the client off to who-knows-where is completely 
wrong in this case.

And of course, there should have been genuine X.500-style knowledge 
references, explicitly set for superior, peer, and subordinate DSAs. Any 
request that doesn't match the known naming contexts, or any of the explicitly 
defined knowledge references, should simply fail with NoSuchObject. The notion 
of "default referral" is just sloppy all around.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/