Bug 431607 - referential integrity plugin incorrectly treats "rename" operations
Summary: referential integrity plugin incorrectly treats "rename" operations
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Server - Plugins
Version: 1.1.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 249650 FDS1.2.0
TreeView+ depends on / blocked
 
Reported: 2008-02-05 21:02 UTC by Andrey Ivanov
Modified: 2015-01-04 23:30 UTC (History)
2 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-29 23:02:24 UTC


Attachments (Terms of Use)

Description Andrey Ivanov 2008-02-05 21:02:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

Description of problem:
The referential integrity plug-in

1. Does not take into account the DNs in the concerned attributes if there is a space in the DN (example : 'ou: ou=Y02, ou=student, ou=organisation, dc=example, dc=com' is not taken into account while 'ou: ou=Y02,ou=student,ou=organisation,dc=example,dc=com' is treated correctly)

2. When the plug-in rewrites the values of these attributes in the case of a rename operation it ADDS SPACES to the DNs itself!!!!

3. So the first rename is treated correctly (if the original attributes contain the DNs without spaces) but the second/third/fourth... one is NEVER treated.

Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
The configuration of the referential integrity plug-in (we'll do our tests on the 'ou' attribute and with the delay of 120 seconds to verify the refer_integrity_log file):

dn: cn=referential integrity postoperation,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: referential integrity postoperation
nsslapd-pluginPath: libreferint-plugin
nsslapd-pluginInitfunc: referint_postop_init
nsslapd-pluginType: postoperation
nsslapd-pluginEnabled: on
nsslapd-pluginarg0: 120
nsslapd-pluginarg1: /Local/dirsrv/var/lib/dirsrv/slapd-dmz/db/refer_integrity_
 log
nsslapd-pluginarg2: 0
nsslapd-pluginarg3: ou
nsslapd-pluginarg4: member
nsslapd-pluginarg5: uniquemember
nsslapd-pluginarg6: owner
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: referint
nsslapd-pluginVersion: 1.1.0
nsslapd-pluginVendor: Fedora Project
nsslapd-pluginDescription: referential integrity plugin
nsslapd-pluginarg7: seeAlso


1. ldapadd -x -D "cn=Directory Manager" -W -f /tmp/example-com.ldif
The file example-com.ldif contains the following :

dn: ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Organisation

dn: ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Student

dn: ou=X02,ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: X02

dn: ou=Users,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Users

dn: uid=marion.henriet,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
sn: Henriet
givenName: Marion
uid: marion.henriet
cn: Henriet Marion
displayName: Henriet Marion (Mlle)
ou: ou=X02,ou=Student,ou=Organisation,dc=example,dc=com

2.ldapmodify -x -D "cn=Directory Manager" -W -f /tmp/first_rename.ldif 
The file first_rename.ldif contains the following :

dn: ou=X02,ou=Student,ou=Organisation,dc=example,dc=com
changetype: modrdn
newrdn: ou=Y02
deleteoldrdn: 1
newsuperior: ou=Student,ou=Organisation,dc=example,dc=com

3. Everything goes fine, in order to verify  (during the next 120seconds) :

cat /Local/dirsrv/var/lib/dirsrv/slapd-dmz/db/refer_integrity_log 
Result : 'ou=x02,ou=student,ou=organisation,dc=example,dc=com     ou=Y02'

4. The server executes the plug-in, the new entries are :

ou=Y02,ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Y02

uid=marion.henriet,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
sn: Henriet
givenName: Marion
uid: marion.henriet
cn: Henriet Marion
displayName: Henriet Marion (Mlle)
ou: ou=Y02, ou=student, ou=organisation, dc=example, dc=com

5. So far so good. But the bug hides just here - the referential integrity plug-in ADDS SPACES in th DN (ou: ou=Y02,<SPACE>ou=student,<SPACE>ou=organisation...). So let us try the second rename

ldapmodify -x -D "cn=Directory Manager" -W -f /tmp/second_rename.ldif
The file second_rename.ldif :
 
dn: ou=Y02,ou=Student,ou=Organisation,dc=example,dc=com
changetype: modrdn
newrdn: ou=Z02
deleteoldrdn: 1
newsuperior: ou=Student,ou=Organisation,dc=example,dc=com

6. Again, the sever takes into account the necessity to use the referential plug-in in 120sec :

cat /Local/dirsrv/var/lib/dirsrv/slapd-dmz/db/refer_integrity_log 
Result : 'ou=y02,ou=student,ou=organisation,dc=example,dc=com     ou=Z02'

7. The referential plug-in does not take into account the attribute 'ou' of the entry 'uid=marion.henriet,ou=Users,dc=example,dc=com' containing the DN with SPACES ('ou=Y02, ou=student, ou=organisation, dc=example, dc=com'), so at the end our directory contains :

ou=Z02,ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Z02

uid=marion.henriet,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
sn: Henriet
givenName: Marion
uid: marion.henriet
cn: Henriet Marion
displayName: Henriet Marion (Mlle)
ou: ou=Y02, ou=student, ou=organisation, dc=example, dc=com


Actual Results:
The second and all subsequent renames are not treated correctly by the referential integrity plug-in, the same thing for the attributes containing the DNs with spaces.

Expected Results:
All the subseauent renames should be treated correctly. The result of the above tests should be :

ou=Z02,ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Z02

uid=marion.henriet,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
sn: Henriet
givenName: Marion
uid: marion.henriet
cn: Henriet Marion
displayName: Henriet Marion (Mlle)
ou: ou=Z02,ou=student,ou=organisation,dc=example,dc=com

Additional info:
I have tested it on FDS 1.1 and 1.04, the problem is the same. I do not know whether the DNs with spaces after the commas are acceptable or not but anyway there are two solutions: 
1. The plug-in rewrites the DNs correctly without adding spaces
2. The plug in rewrites the DNS as it wishes but in this case it should detect the DNs with spaces after comma.

Comment 1 Andrey Ivanov 2008-02-06 10:13:21 UTC
I've looked through the code of the plug-in (the file referint.c). The simplest
solution would be the first one (eliminate the spaces that are added by the
plug-in code). The lines in the code to rewrite : 404 - 414.

Comment 2 Andrey Ivanov 2008-02-06 14:01:23 UTC
Proposed patch (tested, works fine, don't know if there are any interferences
with the rest of the code):


--- referint.c  2007-10-18 02:08:31.000000000 +0200
+++ referint-patched.c  2008-02-06 14:59:00.000000000 +0100
@@ -401,8 +401,8 @@
                       dnsize = 0;
                       for(x=1; dnParts[x] != NULL; x++)
                       { 
-                          /* +2 for space and comma adding later */
-                          dnsize += strlen(dnParts[x]) + 2;    
+                          /* +1 for comma adding later */
+                          dnsize += strlen(dnParts[x]) + 1;    
                       }
                       /* add the newrDN length */
                       dnsize += strlen(newrDN) + 1;
@@ -411,7 +411,7 @@
                       strcat(newDN, newrDN);
                       for(x=1; dnParts[x] != NULL; x++)
                       { 
-                          strcat(newDN, ", ");
+                          strcat(newDN, ",");
                           strcat(newDN, dnParts[x]);
                       }
             

Comment 5 Rich Megginson 2009-02-13 19:22:57 UTC
Andrey - Have you submitted a CLA?  http://directory.fedoraproject.org/wiki/Contributing

I don't see your name or email address in the cla_done group - https://admin.fedoraproject.org/accounts/group/view/cla_done

The process is pretty easy now - basically just create an account in the Fedora Admin system and go through the click through process

If you have submitted a CLA then don't worry about it.

At any rate, I think we can accept the patch anyway considering that it is only a couple of lines.

Comment 6 Rich Megginson 2009-02-13 19:41:49 UTC
Checking in referint.c;
/cvs/dirsec/ldapserver/ldap/servers/plugins/referint/referint.c,v  <--  referint.c
new revision: 1.9; previous revision: 1.8
done

Comment 7 Yi Zhang 2009-04-15 23:04:11 UTC
Bug verified. Bug closed

test is below (i am using the same set of data that Andrey is using)

1. setup DS 8.1 (my platform is on RHEL 5.3 i386)
2. enable referential integrity postoperation plugin
3. restart server
4. setup suffix "dc=example,dc=com"
5. follow Andrey's steps:

5.1 inject all testing data (bv1.ldif is below), and verity it
5.2 do rename with bv2.dlif, and verify it
5.3 do another rename with bv3.ldif and verity it

test result: pass

==================== test output is below:================
<DS81installed>[root@mv32a-vm ~]# /usr/lib/mozldap/ldapsearch -D "cn=directory manager" -w redhat123 -s sub -b "dc=example,dc=com" objectclass=* dn
version: 1
dn: dc=example,dc=com

dn: ou=Organisation,dc=example,dc=com

dn: ou=Student,ou=Organisation,dc=example,dc=com

dn: ou=X02,ou=Student,ou=Organisation,dc=example,dc=com

dn: ou=Users,dc=example,dc=com

dn: uid=marion.henriet,ou=Users,dc=example,dc=com
<DS81installed>[root@mv32a-vm ~]# /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w redhat123 -f ./bv2.ldif 
modifying RDN of entry ou=X02,ou=Student,ou=Organisation,dc=example,dc=com and/or moving it beneath a new parent


<DS81installed>[root@mv32a-vm ~]# /usr/lib/mozldap/ldapsearch -D "cn=directory manager" -w redhat123 -s sub -b "dc=example,dc=com" objectclass=* dn
version: 1
dn: dc=example,dc=com

dn: ou=Organisation,dc=example,dc=com

dn: ou=Student,ou=Organisation,dc=example,dc=com

dn: ou=Y02,ou=Student,ou=Organisation,dc=example,dc=com

dn: ou=Users,dc=example,dc=com

dn: uid=marion.henriet,ou=Users,dc=example,dc=com
<DS81installed>[root@mv32a-vm ~]# ls /var/log/dirsrv/slapd-mv32a-vm/referintls: /var/log/dirsrv/slapd-mv32a-vm/referint: No such file or directory
<DS81installed>[root@mv32a-vm ~]# /usr/lib/mozldap/ldapsearch -D "cn=directory manager" -w redhat123 -s sub -b "dc=example,dc=com" objectclass=*
version: 1
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example

dn: ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Organisation

dn: ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Student

dn: ou=Y02,ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Y02

dn: ou=Users,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Users

dn: uid=marion.henriet,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
sn: Henriet
givenName: Marion
uid: marion.henriet
cn: Henriet Marion
displayName: Henriet Marion (Mlle)
ou: ou=X02,ou=Student,ou=Organisation,dc=example,dc=com
<DS81installed>[root@mv32a-vm ~]# vi bv3.ldif
<DS81installed>[root@mv32a-vm ~]# /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w redhat123 -f ./bv3.ldif modifying RDN of entry ou=Y02,ou=Student,ou=Organisation,dc=example,dc=com and/or moving it beneath a new parent


<DS81installed>[root@mv32a-vm ~]# /usr/lib/mozldap/ldapsearch -D "cn=directory manager" -w redhat123 -s sub -b "dc=example,dc=com" objectclass=*
version: 1
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example

dn: ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Organisation

dn: ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Student

dn: ou=Z02,ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Z02

dn: ou=Users,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Users

dn: uid=marion.henriet,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
sn: Henriet
givenName: Marion
uid: marion.henriet
cn: Henriet Marion
displayName: Henriet Marion (Mlle)
ou: ou=X02,ou=Student,ou=Organisation,dc=example,dc=com

=========== cat bv1.ldif ===============
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example

dn: ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Organisation

dn: ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Student

dn: ou=X02,ou=Student,ou=Organisation,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: X02

dn: ou=Users,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Users

dn: uid=marion.henriet,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
sn: Henriet
givenName: Marion
uid: marion.henriet
cn: Henriet Marion
displayName: Henriet Marion (Mlle)
ou: ou=X02,ou=Student,ou=Organisation,dc=example,dc=com

============= cat bv2.ldif ============
dn: ou=X02,ou=Student,ou=Organisation,dc=example,dc=com
changetype: modrdn
newrdn: ou=Y02
deleteoldrdn: 1
newsuperior: ou=Student,ou=Organisation,dc=example,dc=com

============== cat bv3.ldif ==========
dn: ou=Y02,ou=Student,ou=Organisation,dc=example,dc=com
changetype: modrdn
newrdn: ou=Z02
deleteoldrdn: 1
newsuperior: ou=Student,ou=Organisation,dc=example,dc=com

Comment 8 Chandrasekar Kannan 2009-04-29 23:02:24 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html


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