[JBoss JIRA] Closed: (JBREM-915) NullPointerException in InvokerLocator
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-915?page=all ]
Ron Sigal closed JBREM-915.
---------------------------
Resolution: Done
org.jboss.remoting.InvokerLocator.resolveHost() tests explicitly for host == null.
Testing: Added testNullHost() to org.jboss.test.remoting.locator.InvokerLocatorTestCase.
> NullPointerException in InvokerLocator
> --------------------------------------
>
> Key: JBREM-915
> URL: http://jira.jboss.com/jira/browse/JBREM-915
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jmx remoting
> Affects Versions: 2.2.2.SP4
> Environment: JBEAP 4.3 (JBoss Remoting 2.2.2 SP4)
> Windows 2000
> Reporter: Matthew Brasier
> Assigned To: Ron Sigal
> Priority: Minor
> Fix For: 2.2.2.SP6
>
>
> A NullPointerException is thrown by InvokerLocator.resolveHost if a null host is passed in. (Line 333 of InvokerLocator.java for the 2.2.2SP4 tag)
> This was observed when running JBEAP 4.3 on a laptop that has a VPN client installed. JBoss was configured to bind to all interfaces (-b0.0.0.0) and iIt appears that this configuration results in a null host being passed to resolveHost. resolveHost then does a host.indexOf("0.0.0.0") which throws the NPE.
> On the laptop in question, this can be worked around by explicitly binding the the required IP address, rather than binding to all, but the code should handle the case where a null host is passed in more gracefully.
--
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, 1 month
[JBoss JIRA] Updated: (JBREM-915) NullPointerException in InvokerLocator
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-915?page=all ]
Ron Sigal updated JBREM-915:
----------------------------
Fix Version/s: 2.2.2.SP6
Assignee: Ron Sigal
> NullPointerException in InvokerLocator
> --------------------------------------
>
> Key: JBREM-915
> URL: http://jira.jboss.com/jira/browse/JBREM-915
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jmx remoting
> Affects Versions: 2.2.2.SP4
> Environment: JBEAP 4.3 (JBoss Remoting 2.2.2 SP4)
> Windows 2000
> Reporter: Matthew Brasier
> Assigned To: Ron Sigal
> Priority: Minor
> Fix For: 2.2.2.SP6
>
>
> A NullPointerException is thrown by InvokerLocator.resolveHost if a null host is passed in. (Line 333 of InvokerLocator.java for the 2.2.2SP4 tag)
> This was observed when running JBEAP 4.3 on a laptop that has a VPN client installed. JBoss was configured to bind to all interfaces (-b0.0.0.0) and iIt appears that this configuration results in a null host being passed to resolveHost. resolveHost then does a host.indexOf("0.0.0.0") which throws the NPE.
> On the laptop in question, this can be worked around by explicitly binding the the required IP address, rather than binding to all, but the code should handle the case where a null host is passed in more gracefully.
--
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, 1 month
[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_12403970 ]
Ron Sigal commented on JBREM-920:
---------------------------------
Updated RMIServerInvoker, RMIClientInvoker, and ObjectInputStreamWithClassLoader.
> 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.GA
>
>
> 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, 1 month
[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_12403960 ]
David Lloyd commented on JBREM-920:
-----------------------------------
One more privileged block:
java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:8888 connect,resolve)
[...]
at org.jboss.remoting.transport.rmi.RMIClientInvoker.handleConnect(RMIClientInvoker.java:232)
> 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.GA
>
>
> 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, 1 month
[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_12403959 ]
David Lloyd commented on JBREM-920:
-----------------------------------
Need a privileged block added:
java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:3455 connect,resolve)
[...]
at org.jboss.remoting.transport.rmi.RMIServerInvoker.initRMI(RMIServerInvoker.java:219)
> 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.GA
>
>
> 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, 1 month
[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_12403948 ]
David Lloyd commented on JBREM-920:
-----------------------------------
Many tests are passing despite access failures. I've added a "tripwire" sort of security manager that logs the violations, with interesting results. For example:
java.security.AccessControlException: access denied (java.util.PropertyPermission org.jboss.logging.Logger.pluginClass read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at org.jboss.test.security.LoggingSecurityManager.checkPermission(LoggingSecurityManager.java:22)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
at org.jboss.test.security.LoggingSecurityManager.checkPropertyAccess(LoggingSecurityManager.java:191)
at java.lang.System.getProperty(System.java:662)
at org.jboss.logging.Logger.init(Logger.java:359)
Do we need an updated jboss logging? Ours is: Implementation-Version: 4.0.4beta (build: CVSTag=Branch_4_0 date=200601031254) How do we decide which version to use? I presume that we're getting the above problem because the Logger isn't doing System.getProperty within a privileged block.
> 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.GA
>
>
> 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, 1 month