[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 moved WFLY-5989 to WFCORE-1351:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1351 (was: WFLY-5989)
Component/s: (was: Remoting)
(was: Security Manager)
Target Release: (was: 7.0.0.GA)
Affects Version/s: (was: 10.0.0.CR5)
> 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
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
>
> # 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)
8 years, 4 months
[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 updated WFCORE-1351:
--------------------------------
Fix Version/s: 2.0.11.Final
> 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
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 2.0.11.Final
>
>
> # 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)
8 years, 4 months
[JBoss JIRA] (JGRP-2012) Request: optimize in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2012?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2012 at 2/2/16 8:28 AM:
--------------------------------------------------------
* Removed {{Request.request_msg}}, passed via {{execute()}}
* Removed {{UnicastRequest.num_received}}
** Not done on 3.6.8, as MuxRpcDispatcher requires this field
* Removed {{Request.block_for_results}}
was (Author: belaban):
* Removed {{Request.request_msg}}, passed via {{execute()}}
* Removed {{UnicastRequest.num_received}}
* Removed {{Request.block_for_results}}
> Request: optimize in-memory size
> --------------------------------
>
> Key: JGRP-2012
> URL: https://issues.jboss.org/browse/JGRP-2012
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> {{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
> * {{request_msg}} can be removed and instead passed as arg to {{execute()}}
> * Remove {{UnicastRequest.num_received}} ?
> * Investigate whether more fields can be removed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (JGRP-2012) Request: optimize in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2012?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2012 at 2/2/16 8:01 AM:
--------------------------------------------------------
* Removed {{Request.request_msg}}, passed via {{execute()}}
* Removed {{UnicastRequest.num_received}}
* Removed {{Request.block_for_results}}
was (Author: belaban):
* Removed {{UnicastRequest.num_received}}
* Removed {{Request.block_for_results}}
> Request: optimize in-memory size
> --------------------------------
>
> Key: JGRP-2012
> URL: https://issues.jboss.org/browse/JGRP-2012
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> {{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
> * {{request_msg}} can be removed and instead passed as arg to {{execute()}}
> * Remove {{UnicastRequest.num_received}} ?
> * Investigate whether more fields can be removed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (JGRP-2011) Rsp: optimize in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2011?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2011.
----------------------------
Resolution: Done
> Rsp: optimize in-memory size
> ----------------------------
>
> Key: JGRP-2011
> URL: https://issues.jboss.org/browse/JGRP-2011
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> The in-memory size of {{Rsp}} can be made smaller. Currently, it looks like this:
> {noformat}
> public class Rsp {
> protected boolean received;
> protected boolean suspected;
> protected boolean unreachable;
> protected final Address sender;
> protected T retval;
> protected Throwable exception;
> }
> {noformat}
> Optimizations:
> # received, suspected and unreachable can be compacted into a byte field (flags)
> # retval and exception can be merged into {{Object value}}
> # sender can be removed: {{RspList}} already has the sender
> New format:
> {noformat}
> public class Rsp {
> protected byte flags;
> protected Object value;
> }
> {noformat}
> Size of {{Rsp}} is 32 bytes (used JOL to measure) before, and 24 bytes after the changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-5989) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5989?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-5989:
-------------------------------
Description:
# 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.
was:
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.
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5989
> URL: https://issues.jboss.org/browse/WFLY-5989
> Project: WildFly
> Issue Type: Bug
> Components: Remoting, Security Manager
> Affects Versions: 10.0.0.CR5
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
>
> # 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)
8 years, 4 months