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

[Andrey Ivanov]

Hi Noriko,

Thank you for your patch. The patch you provided does take into
account the modRDN with new superior but it does not seem to take care
of subtree renames (smth like rename "ou=users" to "ou=utilisateurs"
with child entries). For subtree renames all the entries in the
renamed subtree change their DNs so  for each  of these renamed
entries we have to make the search
"slapi_search_internal_set_pb(search_result_pb, search_base,
LDAP_SCOPE_SUBTREE, filter, attrs..." with a different filter.
So for each modrdn we should verify if the renamed entry has any child
entries and if it is the case then treat them either directly or
recursively...

As for the modrdn with newsuperior part i have a question : if
newsuperior=NULL you take the parent of the original entry
slapi_dn_find_parent(origDN) (btw, i haven't found this function in
RHDS plug-in documentation). What does this function return for the
base suffix? Or any rename/move operations are forbidden for the
suffix?

2010/1/26 Noriko Hosoi <nhosoi at redhat.com>:
> 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)
> git patch for ldap/servers/plugins/referint/referint.c
>
> --
> 389-devel mailing list
> 389-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>