Re: (ITS#5344) Wrong check for bad Modify DN

[hyc@symas.com]

h.b.furuseth@usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS:
> URL: http://folk.uio.no/hbf/OpenLDAP/modrdn.diff
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it
> requires newSuperior to be in the same backend.  That does not catch
> moving "cn=x,cn=y" to another database's suffix "cn=z,cn=y".

I don't see how it can miss this.

> Also
> if a database has multiple suffixes it prevents moving an entry
> to one of the suffixes.

OK, I see that.

> slapd/modrdn.c can catch attempts to place an entry above/below itself.
> It doesn't need to send those to the database and hope that catches it.
> This patch puts it in the frontend (fe_op_modrdn); that needed to
> generate the destination DN anyway for the affectsMultipleDSAs check.
> Not sure if that's right or if it should go in do_modrdn() instead.
> (I'm thinking of DN rewriting in rwm, vs. global overlays.)

Probably should look at adding the dest_dn to the op struct, so each backend 
doesn't have to rebuild it.

> In test005-modrdn, the "modrdn with newSuperior as child of target" check
> would not catch anything: It expects failure, but the newSuperior did
> not exist and would fail with noSuchObject in any case.  This patch uses
> newSuperior=target instead, and expects unwillingToPerform.

> I'll apply the patch later, unless someone thinks it should be done
> differently.


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