June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3429) Classloader leak in JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3429?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3429: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1103735 > Classloader leak in JBossCachedAuthenticationManager > ---------------------------------------------------- > > Key: WFLY-3429 > URL: https://issues.jboss.org/browse/WFLY-3429 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > When using a security domain with {{cache-type="default"}}, then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager. > The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment). > One option to solve this issue could be to remove the cache entries which are related to the undeployed application. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3429) Classloader leak in JBossCachedAuthenticationManager

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/WFLY-3429?page=com.atlassian.jira.plugin.... ] Josef Cacek updated WFLY-3429: ------------------------------ Bugzilla Update: (was: Perform) > Classloader leak in JBossCachedAuthenticationManager > ---------------------------------------------------- > > Key: WFLY-3429 > URL: https://issues.jboss.org/browse/WFLY-3429 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > When using a security domain with {{cache-type="default"}}, then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager. > The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment). > One option to solve this issue could be to remove the cache entries which are related to the undeployed application. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3429) Classloader leak in JBossCachedAuthenticationManager

by Josef Cacek (JIRA)

Josef Cacek created WFLY-3429: --------------------------------- Summary: Classloader leak in JBossCachedAuthenticationManager Key: WFLY-3429 URL: https://issues.jboss.org/browse/WFLY-3429 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: 8.1.0.Final Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Critical When using a security domain with {{cache-type="default"}}, then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager. The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment). One option to solve this issue could be to remove the cache entries which are related to the undeployed application. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3345) Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3345?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3345: ------------------------------- Fix Version/s: 9.0.0.Alpha1 > Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows > ---------------------------------------------------------------------- > > Key: WFLY-3345 > URL: https://issues.jboss.org/browse/WFLY-3345 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.CR2 > Reporter: Juergen Zimmermann > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > In clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java I'm getting the following compilation error which IMHO is also a logical error: > {code} > [ERROR] /C:/temp/wildfly-8.1.0.CR2/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java:[42,17] variable attributes might not have been initialized > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3345) Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3345?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-3345: ------------------------------------ PR against master was merged, but the PR against 8.x was not, for whatever reason. > Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows > ---------------------------------------------------------------------- > > Key: WFLY-3345 > URL: https://issues.jboss.org/browse/WFLY-3345 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.CR2 > Reporter: Juergen Zimmermann > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > In clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java I'm getting the following compilation error which IMHO is also a logical error: > {code} > [ERROR] /C:/temp/wildfly-8.1.0.CR2/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java:[42,17] variable attributes might not have been initialized > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3421) Rehashing on view change can result in premature session/ejb expiration

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3421?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3421: ------------------------------- Comment: was deleted (was: PR against master was merged. The 8.x PR was not, for whatever reason.) > Rehashing on view change can result in premature session/ejb expiration > ----------------------------------------------------------------------- > > Key: WFLY-3421 > URL: https://issues.jboss.org/browse/WFLY-3421 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.CR2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > Session/ejb expiration is scheduled only the the owning node of a given session/ejb. When a node leaves each node that assumes ownership of the sessions/ejbs that were previously owned by the leaving node schedules expiration of those sessions. However, view change can also lead to ownership changes for any session/ejb. We are currently handling this properly. If a session/ejb changes ownership, the expiration scheduling is never cancelled, and that session/ejb will expire prematurely, unless the node reacquires ownership. When using sticky sessions, this issue is not apparent, since subsequent requests will direct to the previous owner, who will cancel expiration on the old owner and reschedule expiration on the new owner properly. However, this will be a problem for web sessions if sticky sessions is disabled - and for @Stateful EJBs, if the ejb client receives updated affinity information prior to subsequent requests. > There are at least 2 ways to address this: > # When a request arrives for an existing session/ejb, we immediately cancel any scheduled expiration/eviction. This is currently a unicast, which typically results in a local call - but can go remote if the ownership has changed. Making this a cluster-wide broadcast would fix the issue. > # We can allow the scheduler to expose the set of keys that are currently schedule, and, on topology change, cancel those sessions/ejbs for which the current node is no longer the owner - and reschedule on the new owner. > Option 1 adds an additional cluster-wide RPC per request. > Option 2 adds N*(N-1) unicast RPCs per view change, where N is the cluster size (i.e. each node sends 1 rpc to every other node containing the set of session/ejb IDs to schedule for expiration), > Option 2 is the least invasive solution of the two. > EDIT: There is a 3rd options, i.e. modify the expiration tasks such that they skip expiration if the session/ejb is not owned by the current node. This is prevents the premature expiration issue, but we need some additional strategy to reschedule the session/ejb expiration on the node on the current owner. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3421) Rehashing on view change can result in premature session/ejb expiration

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3421?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3421: ------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6306, https://github.com/wildfly/wildfly/pull/6307) > Rehashing on view change can result in premature session/ejb expiration > ----------------------------------------------------------------------- > > Key: WFLY-3421 > URL: https://issues.jboss.org/browse/WFLY-3421 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.CR2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > Session/ejb expiration is scheduled only the the owning node of a given session/ejb. When a node leaves each node that assumes ownership of the sessions/ejbs that were previously owned by the leaving node schedules expiration of those sessions. However, view change can also lead to ownership changes for any session/ejb. We are currently handling this properly. If a session/ejb changes ownership, the expiration scheduling is never cancelled, and that session/ejb will expire prematurely, unless the node reacquires ownership. When using sticky sessions, this issue is not apparent, since subsequent requests will direct to the previous owner, who will cancel expiration on the old owner and reschedule expiration on the new owner properly. However, this will be a problem for web sessions if sticky sessions is disabled - and for @Stateful EJBs, if the ejb client receives updated affinity information prior to subsequent requests. > There are at least 2 ways to address this: > # When a request arrives for an existing session/ejb, we immediately cancel any scheduled expiration/eviction. This is currently a unicast, which typically results in a local call - but can go remote if the ownership has changed. Making this a cluster-wide broadcast would fix the issue. > # We can allow the scheduler to expose the set of keys that are currently schedule, and, on topology change, cancel those sessions/ejbs for which the current node is no longer the owner - and reschedule on the new owner. > Option 1 adds an additional cluster-wide RPC per request. > Option 2 adds N*(N-1) unicast RPCs per view change, where N is the cluster size (i.e. each node sends 1 rpc to every other node containing the set of session/ejb IDs to schedule for expiration), > Option 2 is the least invasive solution of the two. > EDIT: There is a 3rd options, i.e. modify the expiration tasks such that they skip expiration if the session/ejb is not owned by the current node. This is prevents the premature expiration issue, but we need some additional strategy to reschedule the session/ejb expiration on the node on the current owner. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-795) AdvancedLdap login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-795: -------------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1065515|https://bugzilla.redhat.com/show_bug.cgi?id=1065515] from VERIFIED to CLOSED > AdvancedLdap login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-795 > URL: https://issues.jboss.org/browse/SECURITY-795 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Derek Horton > Fix For: Negotiation_2_2_7 > > Attachments: SECURITY-795.patch > > > AdvancedLdap login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2839) Remote Naming communication exception should be thrown on ConnectException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2839: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1059837|https://bugzilla.redhat.com/show_bug.cgi?id=1059837] from VERIFIED to CLOSED > Remote Naming communication exception should be thrown on ConnectException > -------------------------------------------------------------------------- > > Key: WFLY-2839 > URL: https://issues.jboss.org/browse/WFLY-2839 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException. This is related to WFLY-2198 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using timezone when calculating next timeout

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2840: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1059914|https://bugzilla.redhat.com/show_bug.cgi?id=1059914] from VERIFIED to CLOSED > @Schedule EJB Timer not using timezone when calculating next timeout > -------------------------------------------------------------------- > > Key: WFLY-2840 > URL: https://issues.jboss.org/browse/WFLY-2840 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 8.0.0.Final > > > With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour. > The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern. If it did, then the timer should continue to fire every minute. > {code} > @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*") > {code} > 21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014 > {code} > import javax.ejb.Schedule; > import javax.ejb.Singleton; > import javax.ejb.Startup; > @Startup > @Singleton > public class ScheduleTest { > @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*") > public void helloWorld(Timer time) { > System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2014