[JBoss JIRA] Commented: (JBREM-167) RMI Invoker does not use true remoting marshalling/unmarshalling
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-167?page=comments#action_12402625 ]
Ron Sigal commented on JBREM-167:
---------------------------------
1. org.jboss.remoting.transport.rmi.RMIClientInvoker and RMIServerInvoker now have the ability to marshal and unmarshal in the server to client direction as well as the client to server direction.
2. Marshalling in the client to server direction has been changed so that once an object has been marshalled into a ByteArrayOutputStream, it is not reread from an ObjectInputStream. Instead, the byte array is passed directly to the proxy's transport() method.
3. Just in case, the original version of marshalling/unmarshalling is available by setting the new parameter RMIServerInvoker.RMI_ONEWAY_MARSHALLING (actual value "rmiOnewayMarshalling") to "true". In fact, the original version has been fixed so that it works with JBossSerialization.
Unit tests:
org.jboss.test.remoting.transport.rmi.RMIInvokerTestCase has been split into
* org.jboss.test.remoting.transport.rmi.RMIInvokerNativeMarshallerTestCase and
* org.jboss.test.remoting.transport.rmi.RMIInvokerOnewayMarshallingTestCase
Also, two new tests have been added:
* org.jboss.test.remoting.transport.rmi.RMIInvokerDecoratorTestCase and
* org.jboss.test.remoting.transport.rmi.RMIInvokerOnewayMarshallingTestCase
Waiting for hudson results.
> RMI Invoker does not use true remoting marshalling/unmarshalling
> ----------------------------------------------------------------
>
> Key: JBREM-167
> URL: http://jira.jboss.com/jira/browse/JBREM-167
> Project: JBoss Remoting
> Issue Type: Bug
> Components: transport
> Affects Versions: 1.2.0 final
> Reporter: Tom Elrod
> Assigned To: Ron Sigal
> Priority: Minor
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> In process of fixing JBREM-165 (RMI support for UnifiedInvoker), have added ability to call on mashaller when making request so that can modify payload before sending. Although the RMIInvokerClient does use the configured marshaller, it does not use the configured unmarshaller (RMIInvokerServer is the opposite). This was done to get JBREM-165 working, but is not a total solution and needs to be fixed so anyone can add a marshaller/unmarshaller for RMI invoker that will be called both ways (in and out) on both the client and server.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Commented: (JBREM-920) Create build.xml target to run test suite with a Security Manager
by David Lloyd (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-920?page=comments#action_12401870 ]
David Lloyd commented on JBREM-920:
-----------------------------------
And here I thought I found them all. :-)
Fixes committed, will find out about 6-8 hours from now if it actually works.
> Create build.xml target to run test suite with a Security Manager
> -----------------------------------------------------------------
>
> Key: JBREM-920
> URL: http://jira.jboss.com/jira/browse/JBREM-920
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Ron Sigal
> Assigned To: David Lloyd
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> From Anil Saldana:
> Presuming that you have a test suite and either use ANT or Maven, I
> recommend an extra target to run the test suite in a Java Security
> Manager with minimal permissions. So for ANT, you will have an
> additional target. For MAVEN, you can use a profile.
> The idea is that you have a Java Security Policy file in which you
> provide unlimited permission to third party libraries and minimal
> permissions to your own code. This exercise is to detect critical
> sections of code that need special privileges and get into privileged
> blocks. If you have an extra target for the security manager and your
> test runs happen on hudson, you can detect issues with security manager
> as new code gets added.
> Please do not have one test that does System.setSecurityManager but run
> your entire test suite via the security manager
> (-Djava.security.manager -Djava.security.policy=somefile).
> Example: (Take a look by clicking "Configure" on the LHS)
> http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/
> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s...
> Now if your head is spinning or you do not care about security or do not
> have the time to do it, please tell me. I can engage myself, someone
> from JBoss Security Team or the QA person handling your project to add a
> JIRA issue (and make the build.xml/pom.xml changes for your project).
> Why is this important?
> * Because many customers run JBAS in a security manager and we need to
> detect issues in our own code. Also during a recent integration work
> with JBoss Messaging for the SOA platform, there was one issue with
> remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is
> still reeling). It took some cycles from me also.
> * We need to have tests running in a security manager on an ongoing basis.
> I understand that there are resource issues in various projects. But
> that does not discount the work that we need to do before we ship JBAS. ;)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Updated: (JBREM-167) RMI Invoker does not use true remoting marshalling/unmarshalling
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-167?page=all ]
Ron Sigal updated JBREM-167:
----------------------------
Assignee: Ron Sigal
> RMI Invoker does not use true remoting marshalling/unmarshalling
> ----------------------------------------------------------------
>
> Key: JBREM-167
> URL: http://jira.jboss.com/jira/browse/JBREM-167
> Project: JBoss Remoting
> Issue Type: Bug
> Components: transport
> Affects Versions: 1.2.0 final
> Reporter: Tom Elrod
> Assigned To: Ron Sigal
> Priority: Minor
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> In process of fixing JBREM-165 (RMI support for UnifiedInvoker), have added ability to call on mashaller when making request so that can modify payload before sending. Although the RMIInvokerClient does use the configured marshaller, it does not use the configured unmarshaller (RMIInvokerServer is the opposite). This was done to get JBREM-165 working, but is not a total solution and needs to be fixed so anyone can add a marshaller/unmarshaller for RMI invoker that will be called both ways (in and out) on both the client and server.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Commented: (JBREM-920) Create build.xml target to run test suite with a Security Manager
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-920?page=comments#action_12401859 ]
Ron Sigal commented on JBREM-920:
---------------------------------
Another - javax.management.MBeanServerPermission: name=createMBeanServer actions=:
org.jboss.test.remoting.detection.registry.NetworkRegistryTestCase(java_serialization).testRegistration
java.security.AccessControlException: access denied javax.management.MBeanServerPermission: name=createMBeanServer actions=
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at javax.management.MBeanServerFactory.checkPermission(MBeanServerFactory.java:287)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:167)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:162)
at org.jboss.test.remoting.detection.registry.NetworkRegistryTestCase.testRegistration(NetworkRegistryTestCase.java:57)
> Create build.xml target to run test suite with a Security Manager
> -----------------------------------------------------------------
>
> Key: JBREM-920
> URL: http://jira.jboss.com/jira/browse/JBREM-920
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Ron Sigal
> Assigned To: David Lloyd
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> From Anil Saldana:
> Presuming that you have a test suite and either use ANT or Maven, I
> recommend an extra target to run the test suite in a Java Security
> Manager with minimal permissions. So for ANT, you will have an
> additional target. For MAVEN, you can use a profile.
> The idea is that you have a Java Security Policy file in which you
> provide unlimited permission to third party libraries and minimal
> permissions to your own code. This exercise is to detect critical
> sections of code that need special privileges and get into privileged
> blocks. If you have an extra target for the security manager and your
> test runs happen on hudson, you can detect issues with security manager
> as new code gets added.
> Please do not have one test that does System.setSecurityManager but run
> your entire test suite via the security manager
> (-Djava.security.manager -Djava.security.policy=somefile).
> Example: (Take a look by clicking "Configure" on the LHS)
> http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/
> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s...
> Now if your head is spinning or you do not care about security or do not
> have the time to do it, please tell me. I can engage myself, someone
> from JBoss Security Team or the QA person handling your project to add a
> JIRA issue (and make the build.xml/pom.xml changes for your project).
> Why is this important?
> * Because many customers run JBAS in a security manager and we need to
> detect issues in our own code. Also during a recent integration work
> with JBoss Messaging for the SOA platform, there was one issue with
> remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is
> still reeling). It took some cycles from me also.
> * We need to have tests running in a security manager on an ongoing basis.
> I understand that there are resource issues in various projects. But
> that does not discount the work that we need to do before we ship JBAS. ;)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Commented: (JBREM-920) Create build.xml target to run test suite with a Security Manager
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-920?page=comments#action_12401858 ]
Ron Sigal commented on JBREM-920:
---------------------------------
Another - java.lang.RuntimePermission setContextClassLoader:
org.jboss.test.remoting.classloader.race.bisocket.BisocketClassloaderRaceTestCase(java_serialization).testSequential
java.security.AccessControlException: access denied (java.lang.RuntimePermission setContextClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.Thread.setContextClassLoader(Thread.java:1212)
at org.jboss.test.remoting.classloader.race.ClassloaderRaceTestParent$SimpleInvocationThread.run(ClassloaderRaceTestParent.java:315)
> Create build.xml target to run test suite with a Security Manager
> -----------------------------------------------------------------
>
> Key: JBREM-920
> URL: http://jira.jboss.com/jira/browse/JBREM-920
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Ron Sigal
> Assigned To: David Lloyd
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> From Anil Saldana:
> Presuming that you have a test suite and either use ANT or Maven, I
> recommend an extra target to run the test suite in a Java Security
> Manager with minimal permissions. So for ANT, you will have an
> additional target. For MAVEN, you can use a profile.
> The idea is that you have a Java Security Policy file in which you
> provide unlimited permission to third party libraries and minimal
> permissions to your own code. This exercise is to detect critical
> sections of code that need special privileges and get into privileged
> blocks. If you have an extra target for the security manager and your
> test runs happen on hudson, you can detect issues with security manager
> as new code gets added.
> Please do not have one test that does System.setSecurityManager but run
> your entire test suite via the security manager
> (-Djava.security.manager -Djava.security.policy=somefile).
> Example: (Take a look by clicking "Configure" on the LHS)
> http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/
> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s...
> Now if your head is spinning or you do not care about security or do not
> have the time to do it, please tell me. I can engage myself, someone
> from JBoss Security Team or the QA person handling your project to add a
> JIRA issue (and make the build.xml/pom.xml changes for your project).
> Why is this important?
> * Because many customers run JBAS in a security manager and we need to
> detect issues in our own code. Also during a recent integration work
> with JBoss Messaging for the SOA platform, there was one issue with
> remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is
> still reeling). It took some cycles from me also.
> * We need to have tests running in a security manager on an ongoing basis.
> I understand that there are resource issues in various projects. But
> that does not discount the work that we need to do before we ship JBAS. ;)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Commented: (JBREM-920) Create build.xml target to run test suite with a Security Manager
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-920?page=comments#action_12401857 ]
Ron Sigal commented on JBREM-920:
---------------------------------
Another - java.lang.RuntimePermission accessClassInPackage.sun.net.www.protocol.http
org.jboss.test.remoting.configuration.HTTPConfigurationTestCase(java_serialization_tomcat).testClientConfiguration
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.net.www.protocol.http)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1491)
at java.lang.Class.checkMemberAccess(Class.java:1450)
at java.lang.Class.getMethod(Class.java:983)
at org.jboss.remoting.transport.http.HTTPClientInvoker.getSimulatedTimeout(HTTPClientInvoker.java:582)
at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:138)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:157)
at org.jboss.remoting.Client.invoke(Client.java:1685)
at org.jboss.remoting.Client.invoke(Client.java:589)
at org.jboss.remoting.Client.invoke(Client.java:577)
at org.jboss.test.remoting.configuration.HTTPConfigurationTestCase.testClientConfiguration(HTTPConfigurationTestCase.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567)
Mar 7, 2008 10:45:24 PM org.apache.coyote.http11.Http11BaseProtocol destroy
> Create build.xml target to run test suite with a Security Manager
> -----------------------------------------------------------------
>
> Key: JBREM-920
> URL: http://jira.jboss.com/jira/browse/JBREM-920
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Ron Sigal
> Assigned To: David Lloyd
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> From Anil Saldana:
> Presuming that you have a test suite and either use ANT or Maven, I
> recommend an extra target to run the test suite in a Java Security
> Manager with minimal permissions. So for ANT, you will have an
> additional target. For MAVEN, you can use a profile.
> The idea is that you have a Java Security Policy file in which you
> provide unlimited permission to third party libraries and minimal
> permissions to your own code. This exercise is to detect critical
> sections of code that need special privileges and get into privileged
> blocks. If you have an extra target for the security manager and your
> test runs happen on hudson, you can detect issues with security manager
> as new code gets added.
> Please do not have one test that does System.setSecurityManager but run
> your entire test suite via the security manager
> (-Djava.security.manager -Djava.security.policy=somefile).
> Example: (Take a look by clicking "Configure" on the LHS)
> http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/
> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s...
> Now if your head is spinning or you do not care about security or do not
> have the time to do it, please tell me. I can engage myself, someone
> from JBoss Security Team or the QA person handling your project to add a
> JIRA issue (and make the build.xml/pom.xml changes for your project).
> Why is this important?
> * Because many customers run JBAS in a security manager and we need to
> detect issues in our own code. Also during a recent integration work
> with JBoss Messaging for the SOA platform, there was one issue with
> remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is
> still reeling). It took some cycles from me also.
> * We need to have tests running in a security manager on an ongoing basis.
> I understand that there are resource issues in various projects. But
> that does not discount the work that we need to do before we ship JBAS. ;)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Commented: (JBREM-920) Create build.xml target to run test suite with a Security Manager
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-920?page=comments#action_12401856 ]
Ron Sigal commented on JBREM-920:
---------------------------------
Here's another necessary permission - java.io.SerializablePermission enableSubclassImplementation:
org.jboss.test.remoting.client.ClientSerializationTestCase(java_serialization).testJBossSerialization
Failing for the past 1 build (Since Unstable#88 )
Took 0 seconds.
org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://10.18.0.216:3025/?serializationtype=jboss]
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:738)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:157)
at org.jboss.remoting.Client.invoke(Client.java:1685)
at org.jboss.remoting.Client.invoke(Client.java:589)
at org.jboss.remoting.Client.invoke(Client.java:577)
at org.jboss.test.remoting.client.ClientSerializationTestCase.testJBossSerialization(ClientSerializationTestCase.java:118)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at org.jboss.remoting.transport.socket.SocketClientInvoker.createClientSocket(SocketClientInvoker.java:162)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:1070)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:728)
... 20 more
Caused by: java.security.AccessControlException: access denied (java.io.SerializablePermission enableSubclassImplementation)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.io.ObjectOutputStream.<init>(ObjectOutputStream.java:206)
at org.jboss.serial.io.JBossObjectOutputStream.<init>(JBossObjectOutputStream.java:126)
at org.jboss.serial.io.JBossObjectOutputStream.<init>(JBossObjectOutputStream.java:116)
at org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager.createOutput(JBossSerializationManager.java:63)
at org.jboss.remoting.marshal.serializable.SerializableMarshaller.getMarshallingStream(SerializableMarshaller.java:89)
at org.jboss.remoting.marshal.serializable.SerializableMarshaller.getMarshallingStream(SerializableMarshaller.java:72)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createOutputStream(ClientSocketWrapper.java:204)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:163)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
... 27 more
> Create build.xml target to run test suite with a Security Manager
> -----------------------------------------------------------------
>
> Key: JBREM-920
> URL: http://jira.jboss.com/jira/browse/JBREM-920
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Ron Sigal
> Assigned To: David Lloyd
> Fix For: 2.4.0.CR1 (Pinto)
>
>
> From Anil Saldana:
> Presuming that you have a test suite and either use ANT or Maven, I
> recommend an extra target to run the test suite in a Java Security
> Manager with minimal permissions. So for ANT, you will have an
> additional target. For MAVEN, you can use a profile.
> The idea is that you have a Java Security Policy file in which you
> provide unlimited permission to third party libraries and minimal
> permissions to your own code. This exercise is to detect critical
> sections of code that need special privileges and get into privileged
> blocks. If you have an extra target for the security manager and your
> test runs happen on hudson, you can detect issues with security manager
> as new code gets added.
> Please do not have one test that does System.setSecurityManager but run
> your entire test suite via the security manager
> (-Djava.security.manager -Djava.security.policy=somefile).
> Example: (Take a look by clicking "Configure" on the LHS)
> http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/
> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s...
> Now if your head is spinning or you do not care about security or do not
> have the time to do it, please tell me. I can engage myself, someone
> from JBoss Security Team or the QA person handling your project to add a
> JIRA issue (and make the build.xml/pom.xml changes for your project).
> Why is this important?
> * Because many customers run JBAS in a security manager and we need to
> detect issues in our own code. Also during a recent integration work
> with JBoss Messaging for the SOA platform, there was one issue with
> remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is
> still reeling). It took some cycles from me also.
> * We need to have tests running in a security manager on an ongoing basis.
> I understand that there are resource issues in various projects. But
> that does not discount the work that we need to do before we ship JBAS. ;)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months