June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-822) MBean created via EAR/META-INF/jboss-service.xml from class defined in JBoss module gets wrong TCCL

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-822?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-822: ---------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1054984|https://bugzilla.redhat.com/show_bug.cgi?id=1054984] from VERIFIED to CLOSED > MBean created via EAR/META-INF/jboss-service.xml from class defined in JBoss module gets wrong TCCL > --------------------------------------------------------------------------------------------------- > > Key: WFLY-822 > URL: https://issues.jboss.org/browse/WFLY-822 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Class Loading, Server > Environment: Java 6u31 > Reporter: Zachary Bedell > Assignee: jaikiran pai > Labels: classloader, mbean, modules > Fix For: 8.0.0.Alpha3 > > Attachments: SarTcclTst.tbz > > > When an MBean is loaded from jboss-service.xml within an EAR, the TCCL should point to the EAR deployment so that config files and other resources can be classloaded from the EAR. Under JBoss 7.1.1.Final, the TCCL in a module loaded MBean's start() method is the module's ClassLoader. No reference to the EAR deployment's classloader is available, thus EAR resources are not available within the MBean. > It appears that org.jboss.as.service.AbstractService::invokeLifecycleMethod() incorrectly sets the TCCL to the module's defining classloader rather than the EAR's: > {{{ > protected void invokeLifecycleMethod(final Method method) throws InvocationTargetException, IllegalAccessException { > if (method != null) { > final ClassLoader old = SecurityActions.setThreadContextClassLoader(mBeanInstance.getClass().getClassLoader()); > try { > method.invoke(mBeanInstance); > } finally { > SecurityActions.resetThreadContextClassLoader(old); > } > } > } > }}} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-797) Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-797: -------------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1067612|https://bugzilla.redhat.com/show_bug.cgi?id=1067612] from VERIFIED to CLOSED > Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-797 > URL: https://issues.jboss.org/browse/SECURITY-797 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-797.patch > > > If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail. Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles. > It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set. This causes an exception which in turn causes the authentication attempt to fail. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-796) LdapExtended 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-796?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-796: -------------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1067599|https://bugzilla.redhat.com/show_bug.cgi?id=1067599] from VERIFIED to CLOSED > LdapExtended login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-796 > URL: https://issues.jboss.org/browse/SECURITY-796 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-796.patch > > > LdapExtended 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2198) Remote Naming throws the same exception for different causes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2198: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1053426|https://bugzilla.redhat.com/show_bug.cgi?id=1053426] from VERIFIED to CLOSED > Remote Naming throws the same exception for different causes > ------------------------------------------------------------ > > Key: WFLY-2198 > URL: https://issues.jboss.org/browse/WFLY-2198 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported. > We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. > If all the the servers specified are not not running: > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) > If one of the servers is running, but the client's username/password are incorrect > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 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 1065513|https://bugzilla.redhat.com/show_bug.cgi?id=1065513] 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2047) testConnection should account for deployment classloader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2047?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2047: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1007181|https://bugzilla.redhat.com/show_bug.cgi?id=1007181] from VERIFIED to CLOSED > testConnection should account for deployment classloader > -------------------------------------------------------- > > Key: WFLY-2047 > URL: https://issues.jboss.org/browse/WFLY-2047 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Alpha4 > Environment: All > Reporter: Jay Kumar SenSharma > Assignee: Stefano Maestri > Fix For: 9.0.0.CR1 > > > If a DataSource is created as following: > ++++++++++++++++ > <datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true"> > <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url> > <driver>oracle</driver> > <pool> > <min-pool-size>1</min-pool-size> > <max-pool-size>15</max-pool-size> > </pool> > <security> > <user-name>Test</user-name> > <password>testPassword</password> > </security> > </datasource> > <drivers> > <driver name="oracle" module="com.oracle.jdbc6"> > <driver-class>oracle.jdbc.driver.OracleDriver</driver-class> > </driver> > <driver name="h2" module="com.h2database.h2"> > <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class> > </driver> > </drivers> > ++++++++++++++++ > Then while testing the DataSource the Wildfly throws the following Exception: > +++++++++++++++++++++ > 16:47:10,498 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21] > at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final] > Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base)) > at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101) > at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458) > at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411) > at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490) > at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202) > at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33) > at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474) > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > ++++++++++++++++++++++ -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2995) Using a log4j appender as a custom-handler should invoke the activateOptions if required

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2995?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2995: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1066607|https://bugzilla.redhat.com/show_bug.cgi?id=1066607] from VERIFIED to CLOSED > Using a log4j appender as a custom-handler should invoke the activateOptions if required > ---------------------------------------------------------------------------------------- > > Key: WFLY-2995 > URL: https://issues.jboss.org/browse/WFLY-2995 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Currently the {{OptionHandler.activateOptions}} is only invoked during construction of a log4j appender. This invocation should happen if any property is updated or added. The invocation of this method should also only happen once. Multiple invocation could result in errors or leave the appender in an invalid state. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer + PropertyResolver is broken for vault expressions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBMETA-371: ------------------------------------------------ mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1058959|https://bugzilla.redhat.com/show_bug.cgi?id=1058959] from VERIFIED to CLOSED > DefaultPropertyReplacer + PropertyResolver is broken for vault expressions > -------------------------------------------------------------------------- > > Key: JBMETA-371 > URL: https://issues.jboss.org/browse/JBMETA-371 > Project: JBoss Metadata > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: common > Affects Versions: 7.0.4.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.Final > > > The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname". > This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value". -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on JBEE-146: ---------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from VERIFIED to CLOSED > jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes > -------------------------------------------------------------------------------------- > > Key: JBEE-146 > URL: https://issues.jboss.org/browse/JBEE-146 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final > > > When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs: > {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" > {code} > See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more details. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2493) EL cannot access public methods/fields of non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2493: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from VERIFIED to CLOSED > EL cannot access public methods/fields of non-public classes > ------------------------------------------------------------ > > Key: WFLY-2493 > URL: https://issues.jboss.org/browse/WFLY-2493 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss AS 7.2.0.Final > Reporter: Jonáš Trantina > Fix For: 8.1.0.CR1, 8.1.0.Final > > Attachments: elresolver_stack, reproducer.zip > > > When trying to access public method/field of non-public class that implements public interface via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface. > This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround. > Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking. > I have attached a simple reproducer app as well as a stack trace of the exception. > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 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