March 2008 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-929) Secure remote classloading

by David Lloyd (JIRA)

Secure remote classloading -------------------------- Key: JBREM-929 URL: http://jira.jboss.com/jira/browse/JBREM-929 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Remote classloading should be allowed only if either (a) a security manager is installed (and thus the security manager would create the policy) or (b) a specific option is enabled (which would be disabled by default) to allow it. Also, the remote classloader needs to be able to work with the standard security manager policy - which is to say, that classes loaded from a remote service need to have a unique codeBase URL so that administrators can grant permission to remote classes based on the service from whence they came. -- 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

14 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-947) ConnectionValidator hangs when server dies

by Tim Fox (JIRA)

ConnectionValidator hangs when server dies ------------------------------------------ Key: JBREM-947 URL: http://jira.jboss.com/jira/browse/JBREM-947 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Tim Fox Fix For: 2.2.2.SP7 If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception. In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached. Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time. Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately. E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible. The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared. -- 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

14 years, 5 months

3
9
0 / 0

[JBoss JIRA] Created: (JBREM-949) CLONE [JBREM-947] - ConnectionValidator hangs when server dies

by Ron Sigal (JIRA)

CLONE [JBREM-947] - ConnectionValidator hangs when server dies -------------------------------------------------------------- Key: JBREM-949 URL: http://jira.jboss.com/jira/browse/JBREM-949 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Tim Fox Assigned To: Ron Sigal Fix For: 2.4.0.GA If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception. In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached. Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time. Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately. E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible. The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared. -- 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

14 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-941) SRP SASL integrity/confidentiality protection is failing

by David Lloyd (JIRA)

SRP SASL integrity/confidentiality protection is failing -------------------------------------------------------- Key: JBREM-941 URL: http://jira.jboss.com/jira/browse/JBREM-941 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 See JrppConnection.java (getSaslProperties) - enable the commented-out line and watch SRP blow up. -- 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

15 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-948) Release 2.2.0.SP8

by Ron Sigal (JIRA)

Release 2.2.0.SP8 ----------------- Key: JBREM-948 URL: http://jira.jboss.com/jira/browse/JBREM-948 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal -- 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

15 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-950) Assure version compatibility with earlier versions of Remoting

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-950 URL: http://jira.jboss.com/jira/browse/JBREM-950 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP8 -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-954) InterruptException should not be rethrown as CannotConnectionException

by Galder Zamarreno (JIRA)

InterruptException should not be rethrown as CannotConnectionException ---------------------------------------------------------------------- Key: JBREM-954 URL: http://jira.jboss.com/jira/browse/JBREM-954 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Reporter: Galder Zamarreno Fix For: 2.2.2.SP4 Let's say you have a Swing GUI application that calls an EJB remotely and the client code is waiting to get entry to client side pool (controlled by clientMaxPoolSize). While waiting, the user decides to cancel the operation by interrupting the thread. In that case, the Remoting code does not make a difference between an InterruptedException and any other Exception: MicroSocketClientInvoker.java: protected SocketWrapper getConnection(Marshaller marshaller, UnMarshaller unmarshaller, int timeAllowed) throws Exception { long start = System.currentTimeMillis(); long timeToWait = (timeAllowed > 0) ? timeAllowed : 30000; boolean timedout = !semaphore.attempt(timeToWait); Any Exception thrown from getConnection() is treated as a CannotConnectException try { socketWrapper = getConnection(marshaller, unmarshaller, timeLeft); } catch (Exception e) { // if (bailOut) // return null; semaphore.release(); if (trace) log.trace(this + " released semaphore: " + semaphore.permits()); throw new CannotConnectException( "Can not get connection to server. Problem establishing " + "socket connection for " + locator, e); } The EJB3 layer wraps this in CannotConnectException in a RuntimeException like: throw new RuntimeException("cluster invocation failed, last exception was: ", lastException); This is misleading on the Remoting side. Semantically, the fact that the thread attempting to connect is interrupted shouldn't be translated into a CannotConnectException. Please find attached a test case I've created. -- 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

15 years, 10 months

2
22
0 / 0

[JBoss JIRA] Created: (JBREM-930) Fix chronic testsuite failures

by Ron Sigal (JIRA)

Fix chronic testsuite failures ------------------------------ Key: JBREM-930 URL: http://jira.jboss.com/jira/browse/JBREM-930 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.CR1 (Pinto) Several tests fail either always or intermittently: Always: * org.jboss.test.remoting.marshall.http.metadata.HTTPUnMarshallerMetadataTestCase * org.jboss.test.remoting.transport.http.proxy.HTTPInvokerProxyTestCase * org.jboss.test.remoting.transport.http.raw.HTTPInvokerTestCase Intermittently: * org.jboss.test.remoting.deploy.DualDeploymentTestCase * org.jboss.test.remoting.transport.http.keep_alive.StressHTTPInvokerTestCase -- 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

15 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-955) CLONE [JBREM-954] - InterruptException should not be rethrown as CannotConnectionException

by Ron Sigal (JIRA)

CLONE [JBREM-954] - InterruptException should not be rethrown as CannotConnectionException ------------------------------------------------------------------------------------------ Key: JBREM-955 URL: http://jira.jboss.com/jira/browse/JBREM-955 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.SP4, 2.2.2.SP7 Reporter: Galder Zamarreno Assigned To: Ron Sigal Fix For: 2.2.2.SP8 Let's say you have a Swing GUI application that calls an EJB remotely and the client code is waiting to get entry to client side pool (controlled by clientMaxPoolSize). While waiting, the user decides to cancel the operation by interrupting the thread. In that case, the Remoting code does not make a difference between an InterruptedException and any other Exception: MicroSocketClientInvoker.java: protected SocketWrapper getConnection(Marshaller marshaller, UnMarshaller unmarshaller, int timeAllowed) throws Exception { long start = System.currentTimeMillis(); long timeToWait = (timeAllowed > 0) ? timeAllowed : 30000; boolean timedout = !semaphore.attempt(timeToWait); Any Exception thrown from getConnection() is treated as a CannotConnectException try { socketWrapper = getConnection(marshaller, unmarshaller, timeLeft); } catch (Exception e) { // if (bailOut) // return null; semaphore.release(); if (trace) log.trace(this + " released semaphore: " + semaphore.permits()); throw new CannotConnectException( "Can not get connection to server. Problem establishing " + "socket connection for " + locator, e); } The EJB3 layer wraps this in CannotConnectException in a RuntimeException like: throw new RuntimeException("cluster invocation failed, last exception was: ", lastException); This is misleading on the Remoting side. Semantically, the fact that the thread attempting to connect is interrupted shouldn't be translated into a CannotConnectException. Please find attached a test case I've created. -- 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
6
0 / 0

[JBoss JIRA] Created: (JBREM-934) Put code subject to a security manager in privileged blocks

by Ron Sigal (JIRA)

Put code subject to a security manager in privileged blocks ----------------------------------------------------------- Key: JBREM-934 URL: http://jira.jboss.com/jira/browse/JBREM-934 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Critical Fix For: 2.4.0.GA To run in a the Application Server, which might be run in a security manager, Remoting code must wrap all code that needs security privileges in AccessController.doPrivileged() calls. -- 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
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues March 2008