Bug 1082967 - attribute uniqueness plugin fails when set as a chaining component
Summary: attribute uniqueness plugin fails when set as a chaining component
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.1
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-01 08:21 UTC by Amita Sharma
Modified: 2015-03-05 09:34 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 09:34:13 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Amita Sharma 2014-04-01 08:21:15 UTC
Description of problem:
attribute uniqueness plugin fails when set as a chaining component

Version-Release number of selected component (if applicable):
389-ds-base.x86_64 0:1.3.1.6-24.el7

How reproducible:
Unknown

Steps to Reproduce:
1. Execute tet longduration test - chainingbackend2,
betxn is not the right timing for for chaing the attribute uniqueness.  In the test case CBE2_11, the attribute uniqueness plugin is set as a chaining component:

    dn: cn=config,cn=chaining database,cn=plugins,cn=config
    nspossiblechainingcomponents: cn=attribute uniqueness,cn=plugins,cn=config
    nsactivechainingcomponents: cn=attribute uniqueness,cn=plugins,cn=config

But It does not prevent adding an entry having a duplicated attribute across the chained backends.  By default, the plugin type of the attribute uniqueness plugin is betxnpreoperation since RHEL-7.0.  Once we set it back to preoperation, the functionality works as expected.

    dn: cn=attribute uniqueness,cn=plugins,cn=config
    nsslapd-pluginType: betxnpreoperation
    ==>
    nsslapd-pluginType: preoperation

# ldapadd -x -h localhost -p 13891 -D "cn=test_user,o=my_mux_suffix.com" -w test_passwd
dn: cn=ou0_target_user,ou=my_ou_0,o=my_suffix.com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
cn: ou0_target_user
uid: UID_TOKEN
sn: ou0_target_user sn

adding new entry "cn=ou0_target_user,ou=my_ou_0,o=my_suffix.com"
ldap_add: Constraint violation (19)
    additional info: Another entry with the same attribute value already exists (attribute: "uid")
Actual results:


Expected results:
Test case should PASS

Comment 2 Noriko Hosoi 2014-04-11 18:49:57 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/47777

Comment 3 mreynolds 2014-04-29 20:42:36 UTC
This is issue is two parts.  Ticket 47777 is handling how the attribute uniqueness plugin works with chained backends.  Currently it fails to check remote chained servers.

Then the real issue is that the chaining plugin, which is a database plugin, simply does not call betxn(pre/post) plugins.  This issue is being tracked by the following ticket:

https://fedorahosted.org/389/ticket/47792

Comment 4 mreynolds 2014-05-07 17:02:02 UTC
Fixed upstream via ticket 47792

Comment 6 Amita Sharma 2015-01-29 09:11:58 UTC
 Attribute uniqueness is not working 
=====================================
dn: cn=attribute uniqueness,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: attribute uniqueness
nsslapd-pluginPath: libattr-unique-plugin
nsslapd-pluginInitfunc: NSUniqueAttr_Init
nsslapd-pluginType: betxnpreoperation
nsslapd-pluginEnabled: on
uniqueness-attribute-name: uid
uniqueness-subtrees: o=unused.com
uniqueness-across-all-subtrees: off
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: NSUniqueAttr
nsslapd-pluginVersion: 1.3.3.1
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: Enforce unique attribute values
nsslapd-pluginarg2: o=my_suffix.com
modifiersName: cn=directory manager
modifyTimestamp: 20150129085036Z

[root@dhcp201-126 export]# ldapsearch -x -h localhost -p 13891 -D "cn=test_user,o=my_mux_suffix.com" -w test_passwd -b "cn=o_target_userA,o=my_suffix.com"
# extended LDIF
#
# LDAPv3
# base <cn=o_target_userA,o=my_suffix.com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# o_target_userA, my_suffix.com
dn: cn=o_target_userA,o=my_suffix.com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
cn: o_target_userA
uid: UID_TOKEN
sn: o_target_userA sn

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@dhcp201-126 export]# ldapsearch -x -h localhost -p 13891 -D "cn=test_user,o=my_mux_suffix.com" -w test_passwd -b "cn=o_target_userB,o=my_suffix.com"
# extended LDIF
#
# LDAPv3
# base <cn=o_target_userB,o=my_suffix.com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# o_target_userB, my_suffix.com
dn: cn=o_target_userB,o=my_suffix.com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
cn: o_target_userB
uid: UID_TOKEN
sn: o_target_userB sn

# search result
search: 2
result: 0 Success


Even after changing nsslapd-pluginType to preoperation, it is not working :: 
---------------------------------------------------------------------------
[root@dhcp201-126 export]# ldapmodify -h localhost -p 13891 -D "cn=Directory Manager" -w Secret123 << EOF
> dn: cn=attribute uniqueness,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-pluginType
> nsslapd-pluginType: preoperation
> EOF
modifying entry "cn=attribute uniqueness,cn=plugins,cn=config"


[root@dhcp201-126 export]# vim /etc/dirsrv/slapd-mux/dse.ldif
[root@dhcp201-126 export]# ldapadd -x -h localhost -p 13891 -D "cn=test_user,o=my_mux_suffix.com" -w test_passwd << EOF
> dn: cn=o_target_user1,o=my_suffix.com
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> cn: o_target_user1
> uid: same1
> sn: o_target_user1 sn
> EOF
adding new entry "cn=o_target_user1,o=my_suffix.com"

[root@dhcp201-126 export]# ldapadd -x -h localhost -p 13891 -D "cn=test_user,o=my_mux_suffix.com" -w test_passwd << EOF
> dn: cn=o_target_user2,o=my_suffix.com
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> cn: o_target_user2
> uid: same1
> sn: o_target_user2 sn
> EOF
adding new entry "cn=o_target_user2,o=my_suffix.com"

Please refer detailed results of TET longduration test - chainingbackend2, they all have failed which were expecting errors:: http://dhcp201-126.englab.pnq.redhat.com/qa/archive/ds/10/acceptance/output/Linux/20150129-140229/chainingbackend2/chainingbackend2.run.out.32113

Comment 7 mreynolds 2015-01-29 14:55:54 UTC
There are several problems with your plugin configuration:

[1]  a mismatch between the plugin args, and full attribute names(e.g. uniqueness-subtrees).  

[2] The plugin args is missing "nsslapd-pluginarg1", but you have nsslapd-pluginarg2 set.

The plugin entry should look like this (no nsslapd-pluginarg's):

dn: cn=attribute uniqueness,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: attribute uniqueness
nsslapd-pluginPath: libattr-unique-plugin
nsslapd-pluginInitfunc: NSUniqueAttr_Init
nsslapd-pluginType: betxnpreoperation
nsslapd-pluginEnabled: on
uniqueness-attribute-name: uid
uniqueness-subtrees: o=my_suffix.com
uniqueness-across-all-subtrees: off
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: NSUniqueAttr
nsslapd-pluginVersion: 1.3.3.1
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: Enforce unique attribute values

Comment 8 Amita Sharma 2015-01-30 09:36:00 UTC
Test cases passed with recommended settings, need to fix this in tet code.
Results
=========
 
CBE2_11: expect=0 actual=0
PASS
-- Create user at root level (same uid as the previous user) (error expected)
ldap_add: Constraint violation
ldap_add: additional info: Another entry with the same attribute value already exists (attribute: "uid")
adding new entry cn=o_target_userB,o=my_suffix.com

CBE2_11: expect=19 actual=19
PASS
-- Create user at my_ou_0 level in the chained backend (error expected)
ldap_add: Constraint violation
ldap_add: additional info: Another entry with the same attribute value already exists (attribute: "uid")
adding new entry cn=ou0_target_user,ou=my_ou_0,o=my_suffix.com

CBE2_11: expect=19 actual=19
PASS
-- Create user at my_ou_1 level (locally, but in another backend) (error expected)
ldap_add: Constraint violation
ldap_add: additional info: Another entry with the same attribute value already exists (attribute: "uid")
adding new entry cn=ou1_target_user,ou=my_ou_1,o=my_suffix.com

CBE2_11: expect=19 actual=19
PASS
-- Create user at my_ou_2 level (locally, in the same backend) (error expected)
ldap_add: Constraint violation
ldap_add: additional info: Another entry with the same attribute value already exists (attribute: "uid")
adding new entry cn=ou2_target_user,ou=my_ou_2,o=my_suffix.com

CBE2_11: expect=19 actual=19
PASS
TestCase [CBE2_11] result-> [PASS]

Marking bug as VERIFIED.

Comment 10 errata-xmlrpc 2015-03-05 09:34:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html


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