Bug 1648922

Summary:	during MODRDN referential integrity can fail erronously while updating large groups
Product:	Red Hat Enterprise Linux 7	Reporter:	thierry bordaz <tbordaz>
Component:	389-ds-base	Assignee:	thierry bordaz <tbordaz>
Status:	CLOSED ERRATA	QA Contact:	RHDS QE <ds-qe-bugs>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.3	CC:	bsmejkal, cpelland, lkrispen, mreynolds, msauton, nkinder, pasik, rmeggins, spichugi, tbordaz, vashirov
Target Milestone:	rc	Keywords:	ZStream
Target Release:	7.7
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	389-ds-base-1.3.9.1-1.el7	Doc Type:	If docs needed, set a value
Doc Text:	Cause: during a MODRDN of a group member referential integrity can corrupt its returned code and return an erroneous failure. Consequence: A MODRDN can fail without logged explanation. In addition the same MODRDN will succeed just after the first failing one. Fix: make sure referential integrity MODRDN callback does not corrupt its returned code Result: During MODRDN referential integrity does not fail without logging some explanations.	Story Points:	---
Clone Of:
Clones:	1648924 1659510 (view as bug list)		Environment:
Last Closed:	2019-08-06 12:59:10 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1648924, 1659510

Description thierry bordaz 2018-11-12 13:16:15 UTC

This bug is created as a clone of upstream ticket:
https://pagure.io/389-ds-base/issue/50020

#### Issue Description
During a MODRDN of a member, referential integrity will update the groups containing this member. Under specific conditions, the MODRDN can fail (err=1) and the updated groups leave untouched because of the txn abort.

The conditions are:

 * One of the evaluated group contains more than 128 members
 * the last member (last value) of the group is not the moved entry
 * the last member (last value) of the group is a DN value that contains escaped chars

This bug may look like mystery failure.

Indeed there is no reported failure (plugin or internal op) because this is just a wrong returned code that is returned. 
Also because of the specific conditions it looks like random issue why a given MODRDN succeeds and an other fails.
Finally when the MODRDN fails, a second attempt of the same MODRDN will **succeed**. In fact the DB is unchanged but the first attempt reordered the member values in the entry cache. The target entry (of the MODRDN) becomes the last value of the group.

#### Package Version and Platform
All versions/platform

#### Steps to reproduce
Reproducible TC attached

#### Actual results
MODRDN fails


#### Expected results
MODRDN should succeeds

Comment 2 thierry bordaz 2018-11-15 13:52:39 UTC

Upstream ticket pushed upstream

Comment 7 bsmejkal 2019-04-10 14:04:04 UTC

=============================================================================================== test session starts ===============================================================================================
platform linux -- Python 3.6.3, pytest-4.4.0, py-1.8.0, pluggy-0.9.0 -- /opt/rh/rh-python36/root/usr/bin/python3
cachedir: .pytest_cache
metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-1034.el7.x86_64-x86_64-with-redhat-7.7-Maipo', 'Packages': {'pytest': '4.4.0', 'py': '1.8.0', 'pluggy': '0.9.0'}, 'Plugins': {'metadata': '1.8.0', 'html': '1.20.0'}}
389-ds-base: 1.3.9.1-4.el7
nss: 3.43.0-2.el7
nspr: 4.21.0-1.el7
openldap: 2.4.44-21.el7_6
cyrus-sasl: 2.1.26-23.el7
FIPS: disabled
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/suites/plugins
plugins: metadata-1.8.0, html-1.20.0
collected 1 item                                                                                                                                                                                                  

referint_test.py::test_referential_false_failure PASSED
                                                                                                                                                  [100%]
===================================================================================== 1 passed in 17.67 seconds =====================================================================================

Comment 9 errata-xmlrpc 2019-08-06 12:59:10 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2152