[jboss-jira] [JBoss JIRA] (JGRP-2136) Merge installs the same view
[
https://issues.jboss.org/browse/JGRP-2136?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-2136:
--------------------------------
I found out that this has nothing to do with AUTH or ASYM_ENCRYPT, but with MERGE3
possibly being able to send incorrect MERGE events up the stack, e.g.
* The view is A1={A,B}
* Now we're injecting A2={A} and B2={B} into MERGE3 as a MERGE event
* ==> This will trigget duplicate view installation as GMS doesn't check if the
members of a given view are the same as those of the existing view.
Unit test: DuplicateMergeViewTest.
Merge installs the same view
----------------------------
Key: JGRP-2136
URL: https://issues.jboss.org/browse/JGRP-2136
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.12, 4.0
The cluster is A,B with AUTH and ASYM_ENCRYPT. When a rogue member C (whith an incorrect
auth_value in AUTH) attempts to join, it will be rejected by AUTH. However, while the
subsequent merge attempts also fail (as designed), this leads to spurious MergeView
installations in A and B, e.g.:
{noformat}
** View=[belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|2] (2) [belasmac-17416, belasmac-56188], 1 subgroups:
[belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|3] (2) [belasmac-17416, belasmac-56188], 1 subgroups:
[belasmac-17416|2] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|4] (2) [belasmac-17416, belasmac-56188], 1 subgroups:
[belasmac-17416|3] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|5] (2) [belasmac-17416, belasmac-56188], 1 subgroups:
[belasmac-17416|4] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|6] (2) [belasmac-17416, belasmac-56188], 1 subgroups:
[belasmac-17416|5] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|7] (2) [belasmac-17416, belasmac-56188], 1 subgroups:
[belasmac-17416|6] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|8] (2) [belasmac-17416, belasmac-56188], 1 subgroups:
[belasmac-17416|7] (2) [belasmac-17416, belasmac-56188]
{noformat}
This neither corrupts security of the system (the rogue member cannot merge-join) nor
correctness, but we need to prevent the spurious views. Systems like Infinispan might
start a rebalance on a view, regardless of whether they are the same as before or not.
SOLUTION: the merge leader needs to see if the MergeView it is about to send out is the
same as the current view, and simply drop it if that's the case.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)