August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-846) Remote EJB client using SPNEGO authentication is not thread safe

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-846?page=com.atlassian.jira.plug... ] Darran Lofthouse reassigned SECURITY-846: ----------------------------------------- Assignee: (was: Darran Lofthouse) > Remote EJB client using SPNEGO authentication is not thread safe > ---------------------------------------------------------------- > > Key: SECURITY-846 > URL: https://issues.jboss.org/browse/SECURITY-846 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_2_1_3 > Environment: JBoss EAP 5.2 with JBPAPP-10613 patch installed > Reporter: Tom Fonteyne > > A standalone program uses SPNEGO authentication to call an EJB on the server from several threads at the same time. Some calls will work, some will throw "Invalid User" exceptions -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-105) Memory leak with http remoting jmx

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-105?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned REMJMX-105: --------------------------------------- Assignee: (was: Darran Lofthouse) > Memory leak with http remoting jmx > ---------------------------------- > > Key: REMJMX-105 > URL: https://issues.jboss.org/browse/REMJMX-105 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 2.0.1.Final > Reporter: Andy G > Attachments: screenshot-1.png > > > We see the memory leak with the RemoteConnectionChannel.java when we try to use the JBOSS mbean server connection in web application. > We initialize the JMX connection factory as below > {code:borderStyle=solid} > try { > this.jmxConnector = JMXConnectorFactory.connect(serviceURL, auth); > if (this.jmxConnector != null) { > > MBeanServerConnection mbs = this.jmxConnector.getMBeanServerConnection(); > if (mbs != null) { > this.mbs = mbs; > } > } > > } catch (IOException e) { > connected = false; > > > } > {code} > Then use mbean server connection after scheduled interval say 60 secs to read the mbeans from above mbean server connection. > {code:borderStyle=solid} > private Map<String, Object> getAttributesForMBean(ObjectName objectName, List<String> attributeNames) { > > HashMap<String, Object> attributeMap = new HashMap<String, Object>(); > for (String attributeName : attributeNames) { > Object attributeValue = null; > if (this.hasAttribute(objectName, attributeName)) { > try { > attributeValue = this.mbs.getAttribute(objectName, attributeName); > } catch (Exception e) { > logger.warn("In getAttributes(), for " + objectName + ": " , e); > } > } > attributeMap.put(attributeName, attributeValue); > } > > return attributeMap; > } > {code} > We see that RemoteConnectionChannel keeps accumulating XnioWorkerTaskPool and leads to memory leak. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SASL-78) Invalid manifest section in jboss-sasl JAR

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SASL-78?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned SASL-78: ------------------------------------ Assignee: (was: Darran Lofthouse) > Invalid manifest section in jboss-sasl JAR > ------------------------------------------ > > Key: SASL-78 > URL: https://issues.jboss.org/browse/SASL-78 > Project: SASL Provider > Issue Type: Bug > Components: Build > Affects Versions: 1.0.4.Final, 1.0.5.Final > Reporter: Björn Kautler > > In the {{MANIFEST.MF}} of your {{jboss-sasl}} JAR you have a section {{Build-Information}}. > This violates that JAR specification. > A section in the manifest always refers to an entry in the JAR. > If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest. > Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. (You are still using jboss-parent 7, if you upgrade to 8 or newer, the problem will be gone) > ---- > In my concrete use-case this happened with other JARs with invalid manifest entries: > - I have signed those JARs and included them in a WebStart application > - I started the application with 8u102 32-bit {{javaws}} > - The JARs were downloaded and their entries signatures verified > - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed > This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse: > - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM > - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again > - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between > - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution > Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-299) HTTP Management Interface Configuration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-299?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFCORE-299: --------------------------------------- Assignee: (was: Darran Lofthouse) > HTTP Management Interface Configuration > --------------------------------------- > > Key: WFCORE-299 > URL: https://issues.jboss.org/browse/WFCORE-299 > Project: WildFly Core > Issue Type: Task > Components: Management > Reporter: Darran Lofthouse > Labels: management_security,, management_sso > > Various configuration items are required for the HTTP Management interface, this is a parent task to combine them. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-112) Schemes "http" and "https" are problematic

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-112?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned REMJMX-112: --------------------------------------- Assignee: (was: Darran Lofthouse) > Schemes "http" and "https" are problematic > ------------------------------------------ > > Key: REMJMX-112 > URL: https://issues.jboss.org/browse/REMJMX-112 > Project: Remoting JMX > Issue Type: Bug > Reporter: David Lloyd > Priority: Minor > > Converting the service URI scheme to "http" or "https" from "remote+http"/"http-remoting-jmx" and similar is problematic because the Remoting Endpoint will not support those schemes starting with 5.0, and those schemes will be (re)used for the purpose of proper HTTP or HTTP/2 driven invocation; it is possible or even likely that we will eventually have a true HTTP JMX transport. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2440) Thread pool AccessControlContext Propagation

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2440?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-2440: -------------------------------------- Assignee: (was: Darran Lofthouse) > Thread pool AccessControlContext Propagation > -------------------------------------------- > > Key: WFLY-2440 > URL: https://issues.jboss.org/browse/WFLY-2440 > Project: WildFly > Issue Type: Task > Reporter: Darran Lofthouse > > A decision was made within Java that newly created threads should inherit the access control context of their creator. > In general this was justified on the basis that if you are creating a thread you want it to inherit the permissions you already have. > Once we introduce thread pooling that logic no longer makes as much sense and there is not the same relationship between the thread that triggers it's creation and the long term life of that thread. > This may affect components outside of WildFly but I am raising it here as a top level task. > Should also note that JBoss Threads does already have some protection built in if a security manager is in use but there are times the AccessControlContext will be used without a security manager so more control is required. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-8) Connection state notification suppport

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-8?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned REMJMX-8: ------------------------------------- Assignee: (was: Darran Lofthouse) > Connection state notification suppport > -------------------------------------- > > Key: REMJMX-8 > URL: https://issues.jboss.org/browse/REMJMX-8 > Project: Remoting JMX > Issue Type: Task > Components: Connection, Notifications > Reporter: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-8) Connection state notification suppport

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-8?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated REMJMX-8: ---------------------------------- Fix Version/s: (was: 2.0.2.CR1) > Connection state notification suppport > -------------------------------------- > > Key: REMJMX-8 > URL: https://issues.jboss.org/browse/REMJMX-8 > Project: Remoting JMX > Issue Type: Task > Components: Connection, Notifications > Reporter: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned REMJMX-94: -------------------------------------- Assignee: (was: Darran Lofthouse) > Memory leak in remoting-jmx > --------------------------- > > Key: REMJMX-94 > URL: https://issues.jboss.org/browse/REMJMX-94 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 1.1.3.Final > Reporter: Libor Zoubek > Labels: memory_leak > > In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed. > I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps: > 1. start new thread > 2. assign URL classloader to this thread (point it to jboss-client.jar) > 3. connect & disconnect to jmx-remoting endpoint > In this test no classes don't get GCed which after serveral iterations ends up in OOM. > My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org... > I am not sure if memleak is in remoting-jmx or some other underlying stuff. > I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-94: ----------------------------------- Fix Version/s: (was: 2.0.2.CR1) > Memory leak in remoting-jmx > --------------------------- > > Key: REMJMX-94 > URL: https://issues.jboss.org/browse/REMJMX-94 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 1.1.3.Final > Reporter: Libor Zoubek > Labels: memory_leak > > In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed. > I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps: > 1. start new thread > 2. assign URL classloader to this thread (point it to jboss-client.jar) > 3. connect & disconnect to jmx-remoting endpoint > In this test no classes don't get GCed which after serveral iterations ends up in OOM. > My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org... > I am not sure if memleak is in remoting-jmx or some other underlying stuff. > I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2018