Bug 431607
| Summary: | referential integrity plugin incorrectly treats "rename" operations | ||
|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Andrey Ivanov <andrey.ivanov> |
| Component: | Server - Plugins | Assignee: | Rich Megginson <rmeggins> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Chandrasekar Kannan <ckannan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.1.3 | CC: | benl, yzhang |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 8.1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-04-29 23:02:24 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: | 249650, 493682 | ||
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. 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]);
}
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. 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 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 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 |
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.