The ldap standard allows mod delete then mod add on an object in a single transaction to be valid. Some libraries like python ldap infact do this to simulate mod replace.
Due to the design of the calls in configdse.c and the lack of atomic isolation in cn=config, this does not work. It should be fix.
How is this ticket related to Ticket #48961 - Unable to reset auditfail log to default value of ""?
If it is independent, could you please add a test case? Thanks.
Yes, this is independent.
There is actually a work around in lib389 that prevents the issue.
It has to do with how python ldap does a MOD_REPLACE: It actually converts to a MOD_DELETE and MOD_ADD. By the ldap standard this is allowed, but the configdse.c code it rejects the operation even if it's valid.
I'll add a test case soon for it, it's not an urgent issue.
To fix this, I really need transactions in our ldif backend, which means other work to be done. Pushing this back.
Metadata Update from @firstyear: - Issue assigned to firstyear - Issue set to the milestone: 1.3.7 backlog
Metadata Update from @firstyear: - Issue close_status updated to: None - Issue tagged with: Complex, Investigate
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue set to the milestone: FUTURE (was: 1.3.7 backlog)
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/2078
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.