Bug 522055 - scope check for managed attribute fails
Summary: scope check for managed attribute fails
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Directory Server
Classification: Red Hat
Component: Server - Plugins
Version: 9.0
Hardware: All
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 389_1.2.7 639035
TreeView+ depends on / blocked
 
Reported: 2009-09-09 10:19 UTC by Sudhir D
Modified: 2016-05-06 14:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-06 14:41:34 UTC


Attachments (Terms of Use)
Proposed Patch (1.45 KB, patch)
2010-10-01 21:17 UTC, Nathan Kinder
nhosoi: review+
Details | Diff

Description Sudhir D 2009-09-09 10:19:18 UTC
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

Comment 1 Nathan Kinder 2009-09-09 15:42:15 UTC
(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

Comment 3 Nathan Kinder 2010-10-01 21:17:45 UTC
Created attachment 451123 [details]
Proposed Patch

Comment 4 Nathan Kinder 2010-10-01 21:47:20 UTC
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

Comment 5 Amita Sharma 2011-06-09 13:16:09 UTC
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.

Comment 6 Amita Sharma 2011-06-10 12:20:46 UTC
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

Comment 7 Nathan Kinder 2011-06-10 15:01:46 UTC
(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

Comment 8 Amita Sharma 2011-06-10 16:20:50 UTC
ok, that said I am marking the bug as VERIFIED.


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