[JBoss JIRA] (JGRP-2136) Merge installs the same view
by Bela Ban (JIRA)
[ 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)
9 years, 4 months
[JBoss JIRA] (JGRP-2136) Merge installs the same view
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2136?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2136 at 1/4/17 12:30 PM:
---------------------------------------------------------
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 trigger 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.
was (Author: belaban):
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)
9 years, 4 months
[JBoss JIRA] (JGRP-2136) Merge installs the same view
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2136?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2136 at 1/4/17 12:30 PM:
---------------------------------------------------------
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 trigger 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.
was (Author: belaban):
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 trigger 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)
9 years, 4 months
[JBoss JIRA] (ELY-861) Role assignment not possible for "anonymous" identity
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-861?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-861:
---------------------------------
The RoleDecoder is responsible for getting the roles from the authorization identity. The domain stores a RoleDecoder with each RealmInfo. The SecurityDomain's anonymous identity is constructed from an empty per-Domain RealmInfo and the org.wildfly.security.authz.AuthorizationIdentity#EMPTY identity. The per-Domain RealmInfo is constructed with the org.wildfly.security.authz.RoleDecoder#DEFAULT role decoder. This decoder simply reads roles off of the "Roles" attribute key, which will be empty for the anonymous identity.
One simple solution is to have configuration options for the anonymous identity's role mapper or decoder, which can simply return the set of roles that the anonymous identity should have.
> Role assignment not possible for "anonymous" identity
> -----------------------------------------------------
>
> Key: ELY-861
> URL: https://issues.jboss.org/browse/ELY-861
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta19
>
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2152) HttpManagementResourceDefinition attributes definitions are wrong
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-2152:
-----------------------------------------
Summary: HttpManagementResourceDefinition attributes definitions are wrong
Key: WFCORE-2152
URL: https://issues.jboss.org/browse/WFCORE-2152
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Alpha16
Reporter: ehsavoie Hugonnet
Assignee: ehsavoie Hugonnet
The attributesd are using a reload required write handler while using OperationEntry.Flag.RESTART_RESOURCE_SERVICES in their definition
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7548) Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-7548?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet commented on WFLY-7548:
-----------------------------------------
Should be using ProductConfig instead of Version to build the serverinfo
> Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-7548
> URL: https://issues.jboss.org/browse/WFLY-7548
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0.Final
> Reporter: Kálmán Szalai
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final. I saw WildFly 2.2.0.Final is the Wildfly Core version.
> Additionally the admin interfacde shows:
> Product name: WildFly Full
> Product version: 10.1.0.Final
> Profile: COMMUNITY
> HAL version: 2.8.27.Final
> Core version: 2.8.27.Final
> Wildfly 8 is produced Wildfly 8 version sting on getServerInfo() call.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months