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

[hyc@symas.com]

h.b.furuseth@usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS:
> URL:
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> If a referral object's "ref" DN differs from the entry DN, and
> you update a subordinate of the referral object, the DN part
> of the referral from back-bdb is wrong.
>
> bash$ cat ref.ldif
> dn: o=we
> o: we
> ref: ldap://elsewhere/o=they
> objectClass: referral
> objectClass: extensibleObject
>
> dn: cn=me,o=we
> cn: me
> objectClass: organizationalRole
>
> bash$ ldapadd ...<  ref.ldif
> adding new entry "o=we"
>
> adding new entry "cn=me,o=we"
> ldap_add: Referral (10)
> 	matched DN: o=we
> 	referrals:
> 		ldap://elsewhere/cn=me,o=we

Frankly this whole example doesn't make sense, and RFC4511 doesn't say 
anything specific about it.

A referral is not an alias. If I try to add an entry "cn=me,o=we" then that is 
the DN that the entry must be created with. If something redirects me to 
create "cn=me,o=they" this should be an error - that is not the entry I 
requested the server to create.

In general, I think it is inappropriate for referral URIs to contain DNs. It 
is inappropriate for the server to alter the DN that the client supplied. In 
the case of a search, it is inappropriate for the server to continue the 
search outside the scope specified by the client. E.g., if the client requests 
a subtree search with base "o=we" it is incorrect for the client to receive 
entries based at "o=they". (Aliases are an exception to this behavior, but 
aliases also are only valid for searches, not for any other operation.)

> It works if NULL is changed to&e->e_name at back-bdb/referral.c line 96:
>
> 				rs->sr_ref = referral_rewrite( ref, NULL,
> 					&op->o_req_dn, LDAP_SCOPE_DEFAULT );
>
> I don't quite understand that function though:
> Why does it use default_referral (slapd.conf 'referral')?  That is for
> use when no local backend database handles the operation, which I would
> think means no database's be_chk_referrals() gets be called.  And indeed
> the function uses it if
> 	!be_issuffix( op->o_bd,&op->o_req_ndn )
> which looks to me like a test for whether this function is _not_ to be
> called for this database.

-- 
   -- 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/