Bug 619623

Summary:

attr-unique-plugin ignores requiredObjectClass on modrdn operations

Product:

[Retired] 389

Reporter:

Karsten Sperling <mail>

Component:

Server - Plugins

Assignee:

Nathan Kinder <nkinder>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Viktor Ashirov <vashirov>

Severity:

high

Docs Contact:

Priority:

high

Version:

1.2.6

CC:

amsharma, jgalipea, nkinder

Target Milestone:

---

Target Release:

---

Hardware:

All

OS:

All

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2015-12-07 17:07:04 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:

639035

Attachments:

Description	Flags
Proposed patch	none
Patch	nhosoi: review+

Description Karsten Sperling 2010-07-29 23:56:32 UTC

Description of problem:

The modrdn preoperation check in the attribute uniqueness plugin (uiduniq/uid.c/preop_modrdn()) is missing the check to see if the object being modified has the class specified in requiredObjectClass.

This means that a uniqueness constraint meant to apply only to a certain object class is applied to objects of any class when a modrdn operation is involved.

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

How reproducible:

Reproducible every time

Steps to Reproduce:
1. Add an instance of the attribute uniqueness plugin, e.g. with attribute=sn, requiredObjectClass=inetOrgPerson, markerObjectClass=organizationalUnit
2. Add an object of class person with dn: cn=test,ou=People,... sn=bob
3. Add another object of class person with dn: sn=bill,ou=People,...
4. Attempt to rename sn=bill,ou=People to sn=bob,ou=People.
  
Actual results:

The attribute uniqueness plugin prevents the modrdn operation from completing

Expected results:

The modrdn operation should succeed because the object does not have the requiredObjectClass inetOrgPerson

Additional info:

Comment 1 Karsten Sperling 2010-07-30 05:57:59 UTC

Created attachment 435468 [details]
Proposed patch

Proposed patch. Please review.

Comment 4 Nathan Kinder 2010-10-26 17:06:24 UTC

(In reply to comment #1)
> Created attachment 435468 [details]
> Proposed patch
> 
> Proposed patch. Please review.

Your patch looks good.  I will turn it into a git patch and attach it here.

Let me know once you have signed the CLA so we can push your patch to the source repository.

Comment 5 Nathan Kinder 2010-10-26 18:41:56 UTC

While testing this patch, I found some other problems in the preop_modrdn() function.  The attribute uniqueness plug-in was written before the server supported MODRDN with newsuperior.  The plug-in currently will not handle the case where an entry is moved within the scope that attribute uniqueness is being enforced in.  I will make some changes to the patch to handle this case.

Comment 6 Nathan Kinder 2010-10-27 21:48:38 UTC

Created attachment 456094 [details]
Patch

Comment 7 Nathan Kinder 2010-10-28 16:00:51 UTC

Pushed to master.  Thanks to Karsten for the initial patch contribution, and to Noriko for her review!

Counting objects: 26, done.
Delta compression using 2 threads.
Compressing objects: 100% (17/17), done.
Writing objects: 100% (17/17), 4.75 KiB, done.
Total 17 (delta 13), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   13b9aff..20833de  master -> master

Comment 8 Amita Sharma 2011-06-10 14:33:44 UTC

Steps to Reproduce:
1. Add an instance of the attribute uniqueness plugin, e.g. with attribute=sn,
requiredObjectClass=inetOrgPerson, markerObjectClass=organizationalUnit

ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 -a << EOF
dn: cn=sn uniqueness,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: sn uniqueness
nsslapd-pluginPath: libattr-unique-plugin
nsslapd-pluginInitfunc: NSUniqueAttr_Init
nsslapd-pluginType: preoperation
nsslapd-pluginEnabled: on
nsslapd-pluginarg0: attribute=sn
nsslapd-pluginarg1: markerObjectClass=organizationalUnit
nsslapd-pluginarg2: requiredObjectClass=inetOrgPerson
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: NSUniqueAttr
nsslapd-pluginVersion: 1.2.7.a3.git13ccbd4
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: Enforce unique attribute values
EOF

2. Add an object of class person with dn: cn=test,ou=People,... sn=bob
ldapadd -D "cn=Directory Manager" -w Secret123 -h localhost -p 389 << EOF
dn: cn=test1,dc=example,dc=com
objectClass: top
objectClass: person
cn: test1
sn: bob   


3. Add another object of class person with dn: sn=bill,ou=People,...
ldapadd -D "cn=Directory Manager" -w Secret123 -h localhost -p 389 << EOF
dn: cn=test2,dc=example,dc=com
objectClass: top
objectClass: person
cn: test1
sn: bill 


4. Attempt to rename sn=bill,ou=People to sn=bob,ou=People.

[root@rhel61 schema]# ldapmodify -x -a -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF
dn: cn=test2,dc=example,dc=com                  
changetype: modify
replace: sn          
sn:bob 
EOF              

modifying entry "cn=test2,dc=example,dc=com"

[root@rhel61 schema]# ldapsearch -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b " cn=test2,dc=example,dc=com"
# extended LDIF
#
# LDAPv3
# base < cn=test2,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# test2, example.com
dn: cn=test2,dc=example,dc=com
objectClass: top
objectClass: person
cn: test1
cn: test2
sn: bob

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@rhel61 schema]#