August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SASL-70) ByteStringBuilder constructor with initial byte array ignore this initial bytes

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SASL-70?page=com.atlassian.jira.plugin.sy... ] Peter Skopek updated SASL-70: ----------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-sasl/pull/12 > ByteStringBuilder constructor with initial byte array ignore this initial bytes > ------------------------------------------------------------------------------- > > Key: SASL-70 > URL: https://issues.jboss.org/browse/SASL-70 > Project: WildFly SASL Provider > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Util > Affects Versions: 2.0.0.Alpha1 > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: 2.0.0.Alpha1 > > > When one uses "new ByteStringBuilder(myByteArray)" the myByteArray is not included in the content of this ByteStringBuilder due to lenght field not set to initial length. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SASL-69) AbstractSaslParticipant::evaluateMessage is not handling FAILED state correctly

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SASL-69?page=com.atlassian.jira.plugin.sy... ] Peter Skopek updated SASL-69: ----------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-sasl/pull/12 > AbstractSaslParticipant::evaluateMessage is not handling FAILED state correctly > ------------------------------------------------------------------------------- > > Key: SASL-69 > URL: https://issues.jboss.org/browse/SASL-69 > Project: WildFly SASL Provider > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Util > Affects Versions: 2.0.0.Alpha1 > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: 2.0.0.Alpha1 > > > When exception occurs down in state's evaluateMessage it always end up in the same state instead of FAILED state. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-904) The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client

by Thomas Reinhardt (JIRA)

[ https://issues.jboss.org/browse/WFLY-904?page=com.atlassian.jira.plugin.s... ] Thomas Reinhardt commented on WFLY-904: --------------------------------------- Is there any progress? This is a real showstopper for all applications that want to do security beyound the basic examples. Also, I can NOT confirm that deleting jndi.properties solves the issue (at least in our application, but I may be wrong as it is a fairly complex scenario). One of the advertised features of JBoss7 / WildFly was security by default. This bugs affects what can be done in reality. This needs a fix, asap. If you need any testing or if you can point me to a location in the source where I can start debugging I am more than happy to help out. > The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-904 > URL: https://issues.jboss.org/browse/WFLY-904 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Environment: Eclipse Juno SR2 with JBoss Tools, Mac OS X, Sun JDK 6 > Reporter: Fernando Nasser > Assignee: Darran Lofthouse > Labels: eap6, investigation_required > Attachments: NPEinSimpleSecurityManager, PBOX000075, QSecuredEJB.jar, QSecuredEJB.zip, SecurityRelatedSettings > > > Description of problem: > If one tries and use security enabled EJBs from a remote client (authenticated connection) before connecting first from a servlet both a Server NPE and an erroneous exception are thrown. However, if one uses some servlet-based authentication first, the missing field is "primed" and from that point on the remote application can use the secure EJBs normally, proper Role authorization is checked and enforced etc. With absolutely no changes in configuration, code (incl. annotation) whatsoever. Any number of remote client connections will succeed until you restart the server. Then the errors are back, until you "prime" the Server by connecting using a Servlet. > More complete data is attached, but here are some info: > NPE is thrown at: > org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:394) > Bean method invocation fails with exceptions containing the message: > JBAS011048: Failed to construct component instance > I am using the "other" security context for testing. > I am running the Server in standalone mode. > When I say remote I mean not in the Server, but I am running my client from localhost. > Version-Release number of selected component (if applicable): Seen on EAP 6.1.0 alpha (apparently present on AS 7.1.1 as well). > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SASL-70) ByteStringBuilder constructor with initial byte array ignore this initial bytes

by Peter Skopek (JIRA)

Peter Skopek created SASL-70: -------------------------------- Summary: ByteStringBuilder constructor with initial byte array ignore this initial bytes Key: SASL-70 URL: https://issues.jboss.org/browse/SASL-70 Project: WildFly SASL Provider Issue Type: Bug Security Level: Public (Everyone can see) Components: Util Affects Versions: 2.0.0.Alpha1 Reporter: Peter Skopek Assignee: Peter Skopek Fix For: 2.0.0.Alpha1 When one uses "new ByteStringBuilder(myByteArray)" the myByteArray is not included in the content of this ByteStringBuilder due to lenght field not set to initial length. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SASL-69) AbstractSaslParticipant::evaluateMessage is not handling FAILED state correctly

by Peter Skopek (JIRA)

Peter Skopek created SASL-69: -------------------------------- Summary: AbstractSaslParticipant::evaluateMessage is not handling FAILED state correctly Key: SASL-69 URL: https://issues.jboss.org/browse/SASL-69 Project: WildFly SASL Provider Issue Type: Bug Security Level: Public (Everyone can see) Components: Util Affects Versions: 2.0.0.Alpha1 Reporter: Peter Skopek Assignee: Peter Skopek Fix For: 2.0.0.Alpha1 When exception occurs down in state's evaluateMessage it always end up in the same state instead of FAILED state. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-29) IllegalStateException when patching MBeans are queried during shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-29?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFCORE-29: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1110117, https://bugzilla.redhat.com/show_bug.cgi?id=1120535 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1110117) > IllegalStateException when patching MBeans are queried during shutdown > ---------------------------------------------------------------------- > > Key: WFCORE-29 > URL: https://issues.jboss.org/browse/WFCORE-29 > Project: WildFly Core > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Patching > Reporter: James Livingston > Assignee: Emanuel Muckenhuber > Attachments: shutdownmbeanquery.jar > > > If the MBeans for the patching subsystem are queried during server shutdown, it can result in an IllegalStateException. InstallationManagerService has already had stop() called on it, so the value is null. > This can be reproduced by the attached EJB, which does a MBeanServer.queryMBeans(null, null); from the @PreDestroy method. It's in a loop to ensure it runs after the installation manager gets de-initialised. > java.lang.IllegalStateException > at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.ModelControllerMBeanHelper.queryMBeans(ModelControllerMBeanHelper.java:125) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.queryMBeans(ModelControllerMBeanServerPlugin.java:159) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.PluggableMBeanServerImpl.queryMBeans(PluggableMBeanServerImpl.java:816) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at example.ShutdownMBeanQuery.destroy(ShutdownMBeanQuery.java:23) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-29) IllegalStateException when patching MBeans are queried during shutdown

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFCORE-29?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski commented on WFCORE-29: ------------------------------------------ https://bugzilla.redhat.com/show_bug.cgi?id=1120535 > IllegalStateException when patching MBeans are queried during shutdown > ---------------------------------------------------------------------- > > Key: WFCORE-29 > URL: https://issues.jboss.org/browse/WFCORE-29 > Project: WildFly Core > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Patching > Reporter: James Livingston > Assignee: Emanuel Muckenhuber > Attachments: shutdownmbeanquery.jar > > > If the MBeans for the patching subsystem are queried during server shutdown, it can result in an IllegalStateException. InstallationManagerService has already had stop() called on it, so the value is null. > This can be reproduced by the attached EJB, which does a MBeanServer.queryMBeans(null, null); from the @PreDestroy method. It's in a loop to ensure it runs after the installation manager gets de-initialised. > java.lang.IllegalStateException > at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.ModelControllerMBeanHelper.queryMBeans(ModelControllerMBeanHelper.java:125) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.queryMBeans(ModelControllerMBeanServerPlugin.java:159) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.jmx.PluggableMBeanServerImpl.queryMBeans(PluggableMBeanServerImpl.java:816) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final] > at example.ShutdownMBeanQuery.destroy(ShutdownMBeanQuery.java:23) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1871) NPEs due to non-volatile Protocol variables

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1871?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1871: -------------------------------- If it's only {{up_prot}} and {{down_prot}}, then that's fine as they're mostly read and only written at stack init time, so that's fast. However, making other fields {{volatile}} can have a big impact on perf: the memory barriers established by volatile fields potentially trigger a lot of cache line flushes and (especially with false sharing) a lot of reloading. No problem if this is mostly reads, but fields with a lot of writes might slow things down a lot. Even worse: testing this might yield good perf on one architecture, but bad perf on another; e.g. when cache line sizes differ. Since 1998 the stack architecture has been the same and no-one has ever run into this except WF... > NPEs due to non-volatile Protocol variables > ------------------------------------------- > > Key: JGRP-1871 > URL: https://issues.jboss.org/browse/JGRP-1871 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.4.5, 3.5 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > In WildFly a given channel is created in one thread, but is potentially started in a different thread. Unfortunately, many of the protocol variables that are set during Protocol.init() are non-volatile. This can cause unexpected behavior as seen in WFLY-3727. > To ensure clean initialization for multi-threaded environments like WF, all non-final variables within every JGroups' Protocol should be volatile. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1207) config-properties should be "read-write" by CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1207?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated JBJCA-1207: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1129496 > config-properties should be "read-write" by CLI > ----------------------------------------------- > > Key: JBJCA-1207 > URL: https://issues.jboss.org/browse/JBJCA-1207 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: AS > Affects Versions: 1.0.17.Final > Environment: EAP 6.1.0 > RHEL 6.5 > Reporter: Jooho Lee > Assignee: Jesper Pedersen > Labels: eap6, jboss > > Using CLI, it is possible to control websphere message server but config-properties can not be modified or created because its access-type is read-only. > For example, > {code:title=CLI Command|borderStyle=solid} > /profile=MMPS-dev-03-profile/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=FDSLPublishQueue/config-properties=baseQueueName:write-attribute(name=value,value=test) > { > "outcome" => "failed", > "failure-description" => "JBAS014639: Attribute value is not writable", > "rolled-back" => true > } > {code} > This is because the fact that baseQueueName(config-properties)' access-type is read-only but I don't see any reasons why this attritbute couldn't be writable. > Is there any reasons the attribute has to be read-only? otherwise, it should be read-write. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1207) config-properties should be "read-write" by CLI

by Jooho Lee (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1207?page=com.atlassian.jira.plugin... ] Jooho Lee updated JBJCA-1207: ----------------------------- Summary: config-properties should be "read-write" by CLI (was: config-properties should be "read-writable" by CLI) > config-properties should be "read-write" by CLI > ----------------------------------------------- > > Key: JBJCA-1207 > URL: https://issues.jboss.org/browse/JBJCA-1207 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: AS > Affects Versions: 1.0.17.Final > Environment: EAP 6.1.0 > RHEL 6.5 > Reporter: Jooho Lee > Assignee: Jesper Pedersen > Labels: eap6, jboss > > Using CLI, it is possible to control websphere message server but config-properties can not be modified or created because its access-type is read-only. > For example, > {code:title=CLI Command|borderStyle=solid} > /profile=MMPS-dev-03-profile/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=FDSLPublishQueue/config-properties=baseQueueName:write-attribute(name=value,value=test) > { > "outcome" => "failed", > "failure-description" => "JBAS014639: Attribute value is not writable", > "rolled-back" => true > } > {code} > This is because the fact that baseQueueName(config-properties)' access-type is read-only but I don't see any reasons why this attritbute couldn't be writable. > Is there any reasons the attribute has to be read-only? otherwise, it should be read-write. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 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 2014