#601 multi master replication allows schema violation
Closed: wontfix None Opened 7 years ago by lkrispen.

If an attribute is required by the schema any attempt to delete all values will fail without replication or on a single master.
But if the attribute has two values it is possible to simultaneously delete one value on one master and the other value on the other master - the individual operation is allowed as one value remains. After the two masters have replayed their changes to each other bot values have disappeared.


299                         slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &lmods); 
300                         slapi_mods_init_passin(&smods, mods); 
301                         slapi_mods_add_string (&smods, LDAP_MOD_ADD, ATTR_NSDS5_REPLCONFLICT, "Schema violation"); 
302                         lmods = slapi_mods_get_ldapmods_passout(&smods); 
303                         slapi_pblock_set(pb, SLAPI_MODIFY_MODS, lmods); 


Does this leak lmods? lmods is not freed, and it is overwritten.

good catch, it should have been:

slapi_mods_init_passin(&smods, lmods);

There is a problem with this solution. In fractional replication it might be accepted that on the consumer side entries can violate the schema because required attributes are not replicated.
This is itself problematic for fractional replication between masters, so I am not sure how to procede.

I verified that with the change in comment#8 there is no memory leak. lmods is taken from the pblock, slapimods_add_string it is reallocated an then set back to the pblock. The test was also run with valgrind and didn't show a leak.

After some discussion we cam to the conclusion that fractional replication should not be used to allow schema violations, so it is ok to check the schema for replicated mods.

Is it ok now to commit ?

$git merge ticket601
Updating 36f506d..d9f25b7
ldap/servers/slapd/back-ldbm/ldbm_modify.c | 47 +++++++++++++++++++++++++++++++++++++++--------
ldap/servers/slapd/schema.c | 13 +++++++++++--
ldap/servers/slapd/slapi-plugin.h | 10 ++++++++++
3 files changed, 60 insertions(+), 10 deletions(-)
$ git push origin master
Counting objects: 17, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 2.21 KiB, done.
Total 9 (delta 7), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
36f506d..d9f25b7 master -> master

Metadata Update from @lkrispen:
- Issue assigned to lkrispen
- Issue set to the milestone: 1.3.2 - 09/13 (September)

3 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/601

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

16 days ago

Login to comment on this ticket.