[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1351:
-------------------------------------
OK I think the proper fix is to add a doPrivileged into the remote naming client.. possibly here:
{noformat}
at org.jboss.naming.remote.client.InitialContextFactory.createEndpoint(InitialContextFactory.java:226)
{noformat}
or here:
{noformat}
at org.jboss.naming.remote.client.EndpointCache.get(EndpointCache.java:47)
{noformat}
...to allow the endpoint to be joined with no special permissions.
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 3.0.0.Alpha8
>
> Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
Lin Gao updated WFCORE-1351:
----------------------------
Attachment: 5-no-suppressAccessChecks-permission.stracktrace
4-no-accessDeclaredMembers-permission.stractrace
3-no-addConnectionProvider-permission.stacktrace
2-no-createXnioWorker-permission.stacktrace
1-no-createEndpoint-permission.stacktrace
Based on the permission sets in [NestedRemoteContextTestCase|https://github.com/wildfly/wildfly/blob/maste...], I added the permissions in the following order and get different stack trace:
# no more permissions added -> [^1-no-createEndpoint-permission.stacktrace]
# new RemotingPermission("createEndpoint") -> [^2-no-createXnioWorker-permission.stacktrace]
# new RuntimePermission("createXnioWorker") -> [^3-no-addConnectionProvider-permission.stacktrace]
# new RemotingPermission("addConnectionProvider") -> [^4-no-accessDeclaredMembers-permission.stractrace]
# new RuntimePermission("accessDeclaredMembers") -> [^5-no-suppressAccessChecks-permission.stracktrace]
# new java.lang.reflect.ReflectPermission("suppressAccessChecks") -> Test Pass
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 3.0.0.Alpha8
>
> Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2098:
--------------------------------
Here's an example: say we use TCP and have cluster A,B,C,D,E, which is subsequently split into AB and CDE. There's no way for the AB side of the brain to know that there's a CDE side, and vice versa.
With UDP, it is simple: every side sends a multicast and so the two sides learn of each other. However, with TCP, we have to send messages individually to single members. Without discovery, neither side will know about the other.
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (ELY-624) Add support for SSO and Clustered SSO
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-624:
------------------------------------
Summary: Add support for SSO and Clustered SSO
Key: ELY-624
URL: https://issues.jboss.org/browse/ELY-624
Project: WildFly Elytron
Issue Type: Enhancement
Components: HTTP
Reporter: Darran Lofthouse
Assignee: Pedro Igor
Priority: Critical
Fix For: 1.1.0.Beta9
This issue is to cover the APIs / SPIs and some implementation where Elytron is to be used with container managed SSO / Clustered SSO.
By this we mean authentication mechanisms similar to HTTP Form where we want the resulting SecurityIdentity to be re-used across different HTTP context and possibly in the clustered case across different nodes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2098:
--------------------------------
I attached LESS_PING instead of polluting the message stream here with code... :-)
Yes, the primary goal of discovery is finding the coordinator.
However, a second goal is also to discover all members out there in case of a merge. For instance, consider cluster A,B,C,D,E which falls apart into A,B and C,D,E on a split. Somehow, both sides need to find out who's out there when the network partition heals. MERGE3 delegates this to the discovery protocols as they already have the means of doing this. I don't want to copy this functionality into the merge protocol itself, to prevent duplication of code.
Re MERGE2 and sendInfo(): I don't want discovery to rely on another protocol. Some configs may not even have a merge protocol in it (I've seen that, although I think that's not correct). Also, some new merge protocols may not send an INFO message at all...
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2098:
---------------------------
Attachment: LESS_PING.java
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2098:
---------------------------
Comment: was deleted
(was: In our implementation we created:
{{public class LESS_PING extends PING
{
@Override
public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
{
// no discovery except for the initial request
if ( initial_discovery )
{
try
{
sendDiscoveryRequest( cluster_name, members );
}
catch ( InterruptedIOException ie )
{
;
}
catch ( InterruptedException ex )
{
;
}
catch ( Throwable ex )
{
log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
}
}
}
protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
String logical_name, final Address sender, boolean coord) {
final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
Message.Flag.DONT_BUNDLE)
.putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));
if(stagger_timeout > 0) {
int view_size=view != null? view.size() : 10;
int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
if( rank > 5 )
{
// there will be plenty of responders
log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
local_addr, sender, rank, max_rank_for_response );
}
else
{
long sleep_time = rank == 0 ? Util.random( stagger_timeout )
: stagger_timeout * rank / view_size - (stagger_timeout / view_size);
timer.schedule( new Runnable()
{
@Override
public void run()
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}, sleep_time, TimeUnit.MILLISECONDS );
}
}
else
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}
}
}}
This in effect limits discovery to initial discovery. In addition, discovery only responds if the rank < 5. Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID))
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ]
David Lloyd updated WFCORE-952:
-------------------------------
Fix Version/s: 3.0.0.Alpha8
> Use WildFly Common for null param checks
> ----------------------------------------
>
> Key: WFCORE-952
> URL: https://issues.jboss.org/browse/WFCORE-952
> Project: WildFly Core
> Issue Type: Task
> Reporter: David Lloyd
> Priority: Minor
> Fix For: 3.0.0.Alpha8
>
>
> For each module, do the following:
> * Locate any/all null param check methods in the log msg
> * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed
> * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-623:
------------------------------------
Assignee: Darran Lofthouse
> Checking for anonymous principal by name is insufficient
> --------------------------------------------------------
>
> Key: ELY-623
> URL: https://issues.jboss.org/browse/ELY-623
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
>
> In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}:
> {noformat}
> + if (AnonymousPrincipal.getInstance().getName().equals(name)) {
> + if (! context.authorizeAnonymous(false)) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null);
> + }
> + } else {
> + if (! (context.importIdentity(this) && context.authorize(name, authorize))) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null);
> + }
> }
> {noformat}
> Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months