Description of problem: scope check for managed attribute fails. If a user is moved from within the scope to outside scope, and then rename that user, the corresponding linkAttribute still gets updated. Version-Release number of selected component (if applicable): RHDS 9.0 How reproducible: Everytime Steps to Reproduce: 1. Add link attribute pair configuration as below, dn: cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: Manager Link1 linktype: directReport managedtype: manager linkscope: ou=people,example,dc=com 2. Add a manager and an employee ldap records as below, dn: uid=manager1,ou=people,dc=example,dc=com changetype: add objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: top objectClass: person cn: Manager1 sn: Manager1 uid: manager1 dn: uid=employee1,ou=people,dc=example,dc=com changetype: add objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: Employee 1 sn: Employee 1 uid: employee1 3. Add directReport as employee1 into manager1 ldap record. 4. Delete employee1 from ou=people,dc=example,dc=com and add employee1 record under ou=users,dc=example,dc=com as below, dn: uid=employee1,ou=users,dc=example,dc=com changetype: add objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: Employee 1 sn: Employee 1 uid: employee1 manager: uid=manager1,ou=people,dc=example,dc=com 5. Now, change rdn of employee1 to employee3. 6. Check manager1's directReport. Actual results: manager1's directReport gets changed to cn=employee3,ou=users,dc=example,dc=com Expected results: manager1's directReport should not get changed, as employee1 is now out of scope and should remain as, cn=employee1,ou=people,dc=example,dc=com
(In reply to comment #0) > > 4. Delete employee1 from ou=people,dc=example,dc=com and add employee1 record > under ou=users,dc=example,dc=com as below, > > dn: uid=employee1,ou=users,dc=example,dc=com > changetype: add > objectClass: extensibleobject > objectClass: inetorgperson > objectClass: organizationalPerson > objectClass: person > objectClass: top > cn: Employee 1 > sn: Employee 1 > uid: employee1 > manager: uid=manager1,ou=people,dc=example,dc=com Why is the "manager" attribute being specified here? Since "manager" is a managed attribute, it should not be manipulated by the end user. If you are deleting and adding an entry, it should be added without the managed attribute. It will be added to the entry by the linked attributes plug-in if it falls within the scope. I would also expect that at this stage, the link is one-way (the "uid=manager1" entry should not have a pointer to "uid=employee1"). This is expected since the link management is only controlled from updated to the link attribute. > 5. Now, change rdn of employee1 to employee3. > > 6. Check manager1's directReport. > > Actual results: > > manager1's directReport gets changed to cn=employee3,ou=users,dc=example,dc=com This may be a bug, but I'm not sure just yet. I believe that the only reason that this is occurring is that the managed attribute was manually manipulated in step 4. The MODRDN callback checks if the entry being renamed has any managed attribute values present. If so, it removes the old pointers and adds ones back to it's new name. It does all of this regardless of scope since the managed type should not exist if the entry is out of scope unless the managed attribute value was manually set. Doing this is discouraged, and an ACI should be used to prevent it (although Directory Manager could still violate this rule). > > Expected results: > > manager1's directReport should not get changed, as employee1 is now out of > scope and should remain as, cn=employee1,ou=people,dc=example,dc=com
Created attachment 451123 [details] Proposed Patch
Pushed to master. Thanks to Noriko for her review! Counting objects: 13, done. Delta compression using 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 935 bytes, done. Total 7 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git a7de5f2..a82f612 master -> master
1. Added in cn=config dn: cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config changeType: add objectClass: top objectClass: extensibleObject cn: Manager Link1 linktype: directReport managedtype: manager linkscope: ou=accounting,dc=example,dc=com 2. Add a manager [root@rhel61 ~]# ldapmodify -x -a -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: uid=manager1,ou=accounting,dc=example,dc=com > changetype: add > objectClass: extensibleobject > objectClass: inetorgperson > objectClass: organizationalPerson > objectClass: top > objectClass: person > cn: Manager1 > sn: Manager1 > uid: manager1 > EOF adding new entry "uid=manager1,ou=accounting,dc=example,dc=com" 3. Add an employee [root@rhel61 ~]# ldapmodify -x -a -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: uid=employee1,ou=accounting,dc=example,dc=com > changetype: add > objectClass: extensibleobject > objectClass: inetorgperson > objectClass: organizationalPerson > objectClass: person > objectClass: top > cn: Employee 1 > sn: Employee 1 > uid: employee1 > EOF adding new entry "uid=employee1,ou=accounting,dc=example,dc=com" 4. Add directReport as employee1 into manager1 ldap record. [root@rhel61 ~]# ldapmodify -x -a -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: uid=manager1,ou=accounting,dc=example,dc=com > changetype: modify > replace: directReport > directReport: uid=employee1,ou=accounting,dc=example,dc=com > EOF modifying entry "uid=manager1,ou=accounting,dc=example,dc=com" 5. Check the Manager attribute added : # employee1, Accounting, example.com dn: uid=employee1,ou=Accounting,dc=example,dc=com objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: Employee 1 sn: Employee 1 uid: employee1 manager: uid=manager1,ou=accounting,dc=example,dc=com 6. Now try changing the parent of employee1, moving from one ou to another. # employee1, Product Development, example.com dn: uid=employee1,ou=Product Development,dc=example,dc=com objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: Employee 1 sn: Employee 1 uid: employee1 manager: uid=manager1,ou=accounting,dc=example,dc=com ldapsearch -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "uid=employee1,ou=accounting,dc=example,dc=com" -s sub "(objectclass=*)" # extended LDIF # # LDAPv3 # base <uid=employee1,ou=accounting,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object matchedDN: ou=accounting,dc=example,dc=com 7. Now, change rdn of employee1 to employee3. and Check manager1's directReport. # manager1, Accounting, example.com dn: uid=manager1,ou=Accounting,dc=example,dc=com objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: top objectClass: person cn: Manager1 sn: Manager1 uid: manager1 [root@rhel61 ~]# ldapsearch -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "uid=manager1,ou=accounting,dc=example,dc=com" -s sub "(objectclass=*)" directReport # extended LDIF # # LDAPv3 # base <uid=manager1,ou=accounting,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: directReport # # manager1, Accounting, example.com dn: uid=manager1,ou=Accounting,dc=example,dc=com # search result search: 2 result: 0 Success Result : The directReport attribute itself got deleted from manager1 after deleting the employee1 from the scope suffix.
I have executed some more test cases as suggested by Sankarr and feel that it needs Developer's attention, hence marking the bug as Assigned again. ldapmodify -x -a -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF dn: uid=employee1,ou=accounting,dc=example,dc=com changetype: add objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: Employee 1 sn: Employee 1 uid: employee1 EOF adding new entry "uid=employee1,ou=accounting,dc=example,dc=com" Add directReport as employee1 into manager1 ldap record. [root@rhel61 ~]# ldapmodify -x -a -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF dn: uid=manager1,ou=accounting,dc=example,dc=com changetype: modify replace: directReport directReport: uid=employee1,ou=accounting,dc=example,dc=com EOF modifying entry "uid=manager1,ou=accounting,dc=example,dc=com" Check the Manager attribute added : # employee1, Accounting, example.com dn: uid=employee1,ou=Accounting,dc=example,dc=com objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: Employee 1 sn: Employee 1 uid: employee1 manager: uid=manager1,ou=accounting,dc=example,dc=com sankarr> one question, do u still see the manager attribute for the user?after the modrdn? The answer is YES, 1. Note that my initial rdn was : uid=employee1,ou=Accounting,dc=example,dc=com, now it is uid=employee1,ou=product development,dc=example,dc=com 2. but still I am having the manager attribute in employee entry with the complete dn of manager. 3. although directreport attribute got erased from the manager entry. ldapsearch -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "uid=employee1,ou=product development,dc=example,dc=com" -s sub "(objectclass=*)" manager # base <uid=employee1,ou=product development,dc=example,dc=com> with scope subtree # employee1, Product Development, example.com dn: uid=employee1,ou=Product Development,dc=example,dc=com manager: uid=manager1,ou=accounting,dc=example,dc=com <sankarr> what happens if you change the employee name and keep the same ou? 1. Nothing happens in this case. 2. employee have his manager dn in its manager attribute. 3. And manager is happily having its employee in its directreport attribute with the changed name ofcourse. I think this is fine. <sankarr> 3. what happens if you change the manager RDN? 1. In this case Manager is still having employee dn in its directreport attribute. <Just note the rdn value changed for manager now from Accouting to product development> [root@rhel61 schema]# ldapsearch -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "uid=manager1,ou=product development,dc=example,dc=com" -s sub "(objectclass=*)" directreport # extended LDIF # # LDAPv3 # base <uid=manager1,ou=product development,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: directreport # # manager1, Product Development, example.com dn: uid=manager1,ou=Product Development,dc=example,dc=com directreport: uid=employee2,ou=accounting,dc=example,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 2. But our employee has lost his manager attribute with value. [root@rhel61 schema]# ldapsearch -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "uid=employee2,ou=accounting,dc=example,dc=com" -s sub "(objectclass=*)" manager # extended LDIF # # LDAPv3 # base <uid=employee2,ou=accounting,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: manager # # employee2, Accounting, example.com dn: uid=employee2,ou=Accounting,dc=example,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
(In reply to comment #6) > 2. But our employee has lost his manager attribute with value. > > [root@rhel61 schema]# ldapsearch -x -h localhost -p 389 -D "cn=directory > manager" -w Secret123 -b "uid=employee2,ou=accounting,dc=example,dc=com" -s sub > "(objectclass=*)" manager > # extended LDIF > # > # LDAPv3 > # base <uid=employee2,ou=accounting,dc=example,dc=com> with scope subtree > # filter: (objectclass=*) > # requesting: manager > # > > # employee2, Accounting, example.com > dn: uid=employee2,ou=Accounting,dc=example,dc=com > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 This is the expected result. This is happening because you moved the manager entry (the one with the directReport attribute in it) outside of the scope of the plug-in: linkscope: ou=accounting,dc=example,dc=com
ok, that said I am marking the bug as VERIFIED.