[389-devel] Please review: [Bug 557224] subtree rename breaks the referential integrity plug-in

[Noriko Hosoi]

https://bugzilla.redhat.com/show_bug.cgi?id=557224

Description of problem:
Analysis by andrey.ivanov at polytechnique.fr
>  I'm pretty sure the referential integrity plug-in will not work for
>  modrdn operations with a new superior. Looking more thoroughly through
>  the code ( ldap / servers / plugins / referint / referint.c) confirms
>  my suspicion that new rdn superior is not taken into account. The
>  function  referint_postop_modrdn extracts from the parameter block
>  only SLAPI_MODRDN_TARGET and SLAPI_MODRDN_NEWRDN, it does not extract
>  SLAPI_MODRDN_NEWSUPERIOR neither passes it further down the utility
>  functions - update_integrity(argv, dn, newrdn, logChanges) and
>  writeintegritylog(argv[1],dn, newrdn). The same applies to the delayed
>  referint operations (the plug-in writes to the special integrity log
>  file only the old DN and the new RDN, but never the new superior :
>  writeintegritylog(argv[1],dn, newrdn);)

Another thought on the subject of referential integrity plug-in - in
the previous mail i have only mentioned one-entry renames with a new
superior. The things get even worse when we rename a whole non-empty
sub-tree. It means that the referential integrity plug-in should
change to the new DNs all the references to all the entries of the
whole sub-tree, not only for one entry.

And what if we rename a sub-tree containing both the referenced entry
and the entry referencing the first one's DN in one of its "integrity"
attributes? It actually means that we need at first make the rename
and then all the searches and replacements. Though it seems it's
already the case as it's a post-op(?) plug-in...

Fix Description: The referential integrity plugin has not supported
the subtree rename (modrdn with newsuperior).  This patch is adding
the support.

Created an attachment (id=386896)  <https://bugzilla.redhat.com/attachment.cgi?id=386896&action=diff>
git patch for ldap/servers/plugins/referint/referint.c


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/389-devel/attachments/20100126/83a5551f/attachment.html