Bug 838706 – referint modrdn not working if case is different

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 838706 - referint modrdn not working if case is different

Summary:	referint modrdn not working if case is different

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	389-ds-base (Show other bugs)
Sub Component:
Version:	6.4
Hardware:	Unspecified Unspecified

Priority	medium Severity unspecified
Target Milestone:	rc
Target Release:	---
Assigned To:	Rich Megginson
QA Contact:	Sankar Ramalingam
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2012-07-09 16:51 EDT by Nathan Kinder
Modified:	2013-02-21 03:20 EST (History)
CC List:	2 users (show)

See Also:
Fixed In Version:	389-ds-base-1.2.11.12-1.el6
Doc Type:	Bug Fix
Doc Text:	Cause: Enabling the Referential Integrity plugin, with existing ou=People and ou=Groups container entries (note - begins with upper case letter), and renaming a user in ou=People that is also a member of one or more groups in ou=Groups, and the modrdn operation specifies the user DN using ou=people (note begins with lower case letter). Consequence: Group entries that have a member DN of the user that have an upper case ou=People are not changed to reflect the new name of the user. Fix: Make sure to do case-insensitive comparisons and/or normalize the DNs so that comparisons work. Result: The member attributes are updated when the user is renamed.
Story Points:	---
Clone Of:
Environment:
Last Closed:	2013-02-21 03:20:01 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2013:0503	normal	SHIPPED_LIVE	Moderate: 389-ds-base security, bug fix, and enhancement update	2013-02-21 03:18:44 EST

Groups: None (edit)

Description Nathan Kinder 2012-07-09 16:51:36 EDT

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/405

Steps:
* setup directory server with DIT
dc=example,dc=com
ou=People,dc=example,dc=com # NOTE uppercase People
ou=Groups,dc=example,dc=com
* Enable referint
* Add group entry cn=allusers,ou=Groups,dc=example,dc=com like this:
{{{
dn: cn=allusers,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupofNames
cn: allusers
description: default group for users
}}}

* Add a user entry uid=testuser1,ou=People,dc=example,dc=com
* Add member: uid=testuser1,ou=people,dc=example,dc=com to cn=allusers group
* modrdn uid=testuser1
ldapmodify ... <<EOF
changetype: modrdn
newrdn: uid=testuser1changed
deleteoldrdn: 1
EOF

* search cn=allusers - it still lists the old dn
member: uid=testuser1,ou=people,dc=example,dc=com

Looking at the referint code, _update_one_per_mod() and _update_all_per_mod() are doing a PL_strstr - comparing a case normalized value against an un-case normalized value (that is, normalized but not case normalized).

Comment 1 Rich Megginson 2012-07-09 18:40:02 EDT

r6718 | rmeggins@REDHAT.COM | 2012-07-09 16:37:36 -0600 (Mon, 09 Jul 2012) | 1 line
Changed paths:
   M /trunk/testcases/DS/6.0/mbo/acceptance/mboModRdn.sh
   M /trunk/testcases/DS/6.0/mbo/acceptance/mboScen

added test for Bug 838706 - referint modrdn not working if case is different

Comment 3 Amita Sharma 2013-01-29 01:28:21 EST

Mbo startup 	100% (3/3) 	  	 
MemberOf run 	100% (75/75) 	  	 
MemberOf cleanup 	100% (1/1)
All tests passed in the acceptance with 389-ds-base.x86_64 0:1.2.11.15-10.el6 build on rhel64.

Hence marking bug as VERIFIED.

Comment 4 errata-xmlrpc 2013-02-21 03:20:01 EST

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.

http://rhn.redhat.com/errata/RHSA-2013-0503.html

Note You need to log in before you can comment on or make changes to this bug.