-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
No
-
Low
-
ZStream
-
rhel-idm-ds
-
0
-
False
-
False
-
-
None
-
None
-
Regression Exception
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
None
Description of a problem
Performing modRDN operation on an entry can violate configured attribute uniqueness.
Version-Release number of the selected component
389-ds-base-3.0.6-8.el10_0.x86_64
Steps to reproduce
1. Setup attribute uniqueness plugin to keep 'cn' attribute unique
within ou=People,dc=example,dc=com subtree and restart the instance
dn: cn=CN Uniqueness,cn=plugins,cn=config cn: CN Uniqueness nsslapd-plugin-depends-on-type: database nsslapd-pluginDescription: Enforce unique attribute values nsslapd-pluginEnabled: on nsslapd-pluginId: NSUniqueAttr nsslapd-pluginInitfunc: NSUniqueAttr_Init nsslapd-pluginPath: libattr-unique-plugin nsslapd-pluginType: betxnpreoperation nsslapd-pluginVendor: 389 Project nsslapd-pluginVersion: 3.0.6 objectClass: top objectClass: nsslapdplugin objectClass: extensibleObject uniqueness-attribute-name: cn uniqueness-subtrees: ou=People,dc=example,dc=com
2. Create two users with different cn under ou=People
dn: uid=user1,ou=people,dc=example,dc=com cn: user1 ... dn: uid=user2,ou=people,dc=example,dc=com cn: user2 ...
3. Try to rename user2 with cn=user1 (modRDN)
dn: uid=user2,ou=people,dc=example,dc=com changetype: modrdn newrdn: cn=user1 deleteoldrdn: 0
Actual results
Rename operation succeeded
dn: cn=user1,ou=people,dc=example,dc=com cn: user2 cn: user1 ...
Expected results
Rename operation should fail as cn=user1 is already used within enabled attribute uniqueness scope
- links to