#47777 attribute uniqueness plugin fails when set as a chaining component
Closed: Duplicate None Opened 5 years ago by nhosoi.

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

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:


The RI plugin is also a possible chaining component, but it is also a betxn plugin - which means it will never be called for a chaining delete operation.

So it looks like we need a way for "database" plugins to call backend transaction plugins - I will file a new ticket for this. Then just like the proposed fix in this ticket, RI plugin would need to know how to look at sub-suffixes individually.

Maybe the way to fix this is to allow the chaining database to call BE[TXN][PRE|POST] operation plugins. We did the same thing in the dse.c code - basically, make the dse backend code follow the same semantics as the ldbm backend code when calling plugins. We could do the same in the chaining plugin. If/when we support external LDAP transactions, and we support them through chaining, then the use of these plugins will have the same transactional semantics as the ldbm plugins.

The attached patch does not change the plugin type in the config(that can be done manually for now), but we still need to change how the the "attribute uniqueness plugin" looks for duplicates: by checking all the backend suffixes that are sub-suffixes of the plugin's configured suffix.

So we have a regular backend "dc=example,dc=com" (this is also what is set in the attribute uniqueness plugin), and then we have these two chained backends:

ou=people,dc=example,dc=com (backend #2)
ou=groups,dc=example,dc=com (backend #3)

When we add a user to "ou=people,dc=example,dc=com", we need to search all three backends(not just the configured one). So if we use the default suffix in the uniqueness plugin(dc=example,dc=com), it will not check the chained backends for uniqueness(not even the one we are adding it to). You need to explicitly search on "ou=people,dc=example,dc=com", or "ou=groups,...", in order to check that remote/chained backend.

You have my ack. I'm wondering we should change the plugin type with your fix?

Replying to [comment:6 mreynolds]:

The attached patch does not change the plugin type in the config(that can be done manually for now),
I see that in your comment (btw, found a typo "swsitch" ;). But why you don't change it back to preop by default?
Currently, you need to swsitch it back to preoperation plugin,
but that is not enough...

Replying to [comment:7 nhosoi]:

You have my ack. I'm wondering we should change the plugin type with your fix?

Replying to [comment:6 mreynolds]:

The attached patch does not change the plugin type in the config(that can be done manually for now),
I see that in your comment (btw, found a typo "swsitch" ;). But why you don't change it back to preop by default?
Currently, you need to swsitch it back to preoperation plugin,
but that is not enough...

If you change it from betxn, that will apply to all operations, which means it may break applications that expect the referint work to be done inside the transaction . . .

Replying to [comment:8 rmeggins]:

If you change it from betxn, that will apply to all operations, which means it may break applications that expect the referint work to be done inside the transaction . . .

Ah, I see. Thanks, Rich.

I don't understand. The search code (op_shared_search) should be doing this checking for sub-suffixes and sub-databases. If this is the problem, then we will need to fix every single place in the server code where an internal subtree search can be done. Am I missing something here?

Replying to [comment:10 rmeggins]:

I don't understand. The search code (op_shared_search) should be doing this checking for sub-suffixes and sub-databases. If this is the problem, then we will need to fix every single place in the server code where an internal subtree search can be done. Am I missing something here?

In my testing, if the search base was "dc=example,dc=com", it would not return entries from the chained backend: "ou=chained,dc=example,dc=com"

ldapsearch -xLLL -b "dc=example,dc=com" ou=chained

ldapsearch -xLLL -b "ou=chained,dc=example,dc=com" ou=chained

dn: ou=chained,dc=example,dc=com
ou: chained
objectClass: top
objectClass: organizationalunit

Replying to [comment:11 mreynolds]:

Replying to [comment:10 rmeggins]:

I don't understand. The search code (op_shared_search) should be doing this checking for sub-suffixes and sub-databases. If this is the problem, then we will need to fix every single place in the server code where an internal subtree search can be done. Am I missing something here?

In my testing, if the search base was "dc=example,dc=com", it would not return entries from the chained backend: "ou=chained,dc=example,dc=com"

ldapsearch -xLLL -b "dc=example,dc=com" ou=chained

ldapsearch -xLLL -b "ou=chained,dc=example,dc=com" ou=chained

dn: ou=chained,dc=example,dc=com
ou: chained
objectClass: top
objectClass: organizationalunit

Why is that?

Replying to [comment:12 rmeggins]:

Replying to [comment:11 mreynolds]:

Replying to [comment:10 rmeggins]:

I don't understand. The search code (op_shared_search) should be doing this checking for sub-suffixes and sub-databases. If this is the problem, then we will need to fix every single place in the server code where an internal subtree search can be done. Am I missing something here?

In my testing, if the search base was "dc=example,dc=com", it would not return entries from the chained backend: "ou=chained,dc=example,dc=com"

ldapsearch -xLLL -b "dc=example,dc=com" ou=chained

ldapsearch -xLLL -b "ou=chained,dc=example,dc=com" ou=chained

dn: ou=chained,dc=example,dc=com
ou: chained
objectClass: top
objectClass: organizationalunit

Why is that?

It selects the backend to search based on the base DN supplied. It does it for internal searches as well.

Replying to [comment:13 mreynolds]:

Replying to [comment:12 rmeggins]:

Replying to [comment:11 mreynolds]:

Replying to [comment:10 rmeggins]:

I don't understand. The search code (op_shared_search) should be doing this checking for sub-suffixes and sub-databases. If this is the problem, then we will need to fix every single place in the server code where an internal subtree search can be done. Am I missing something here?

In my testing, if the search base was "dc=example,dc=com", it would not return entries from the chained backend: "ou=chained,dc=example,dc=com"

ldapsearch -xLLL -b "dc=example,dc=com" ou=chained

ldapsearch -xLLL -b "ou=chained,dc=example,dc=com" ou=chained

dn: ou=chained,dc=example,dc=com
ou: chained
objectClass: top
objectClass: organizationalunit

Why is that?

It selects the backend to search based on the base DN supplied. It does it for internal searches as well.

Oh this is my fault. I created "ou=people" as a separate backend, not a sub suffix of "dc=example,dc=com". Okay, scratch this patch.

Closing ticket, tracking issue in ticket #47792

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.1.23

2 years ago

Login to comment on this ticket.

Metadata