April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-803) SecureIdentityLoginModule (and ConfiguredIdentityLoginModule) results are not cached by the JAAS cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-803?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-803: -------------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1069886|https://bugzilla.redhat.com/show_bug.cgi?id=1069886] from MODIFIED to POST > SecureIdentityLoginModule (and ConfiguredIdentityLoginModule) results are not cached by the JAAS cache > ------------------------------------------------------------------------------------------------------ > > Key: SECURITY-803 > URL: https://issues.jboss.org/browse/SECURITY-803 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-803.patch > > > In EAP 6, when using the SecureIdentityLoginModule to encrypt datasource passwords, the results are not cached by the JAAS cache. In EAP 5, the results are cached. This can lead to a performance issue. > The root cause appears to be that the EAP 6 JAAS cache does not allow for a JAAS cache key to be null. > The issue only occurs when the application that uses the datasource is not secured. In this situation, the principal is null when isValid() and updateCache() are called. When the application is secured, the results are cached. I think it is working because the result of the SecureIdentityLoginModule are cached using the authenticated user's principal as the cache key. > Workaround: > Use vault for encrypting the database password. This does not use a JAAS login module so the JAAS cache and login module are completely avoided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1170) Add WARN for <url-delim>

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1170?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1170. ---------------------------------- Fix Version/s: (was: 1.2.0.CR1) Resolution: Duplicate Issue > Add WARN for <url-delim> > ------------------------ > > Key: JBJCA-1170 > URL: https://issues.jboss.org/browse/JBJCA-1170 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > > Add a WARN when <url-delim> is used for either <data-source> or <xa-data-source>, as the feature is unsafe to use in production environments. > There is a potential for data loss too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 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: ----------------------------------------------- Matous Jobanek <mjobanek(a)redhat.com> changed the Status of [bug 1029387|https://bugzilla.redhat.com/show_bug.cgi?id=1029387] from ON_QA to VERIFIED > 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.0.0.Final, 8.1.0.CR1 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 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: ---------------------------------------------- Matous Jobanek <mjobanek(a)redhat.com> changed the Status of [bug 1029387|https://bugzilla.redhat.com/show_bug.cgi?id=1029387] from ON_QA to VERIFIED > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-939) Class-Path manifest entries for WARs-in-EAR not handled properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-939?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-939: ---------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 955818|https://bugzilla.redhat.com/show_bug.cgi?id=955818] from ON_QA to VERIFIED > Class-Path manifest entries for WARs-in-EAR not handled properly > ---------------------------------------------------------------- > > Key: WFLY-939 > URL: https://issues.jboss.org/browse/WFLY-939 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 8.0.0.Alpha1 > > > ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken. > https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml > The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader. > When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR. > When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run. > I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-822) Remove the 'NET' project from JBoss Negotiation

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-822?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-822: -------------------------------------- Fix Version/s: Negotiation_2_2_8 > Remove the 'NET' project from JBoss Negotiation > ----------------------------------------------- > > Key: SECURITY-822 > URL: https://issues.jboss.org/browse/SECURITY-822 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_8, Negotiation_2_3_1_Final > > > The net project is not used in AS 7, EAP 6 or WildFly so time to delete it. > In WildFly 9 an alternative SASL based approach will be used for EJB invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-822) Remove the 'NET' project from JBoss Negotiation

by Darran Lofthouse (JIRA)

Darran Lofthouse created SECURITY-822: ----------------------------------------- Summary: Remove the 'NET' project from JBoss Negotiation Key: SECURITY-822 URL: https://issues.jboss.org/browse/SECURITY-822 Project: PicketBox Issue Type: Bug Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2_3_1_Final The net project is not used in AS 7, EAP 6 or WildFly so time to delete it. In WildFly 9 an alternative SASL based approach will be used for EJB invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-821) SPNEGOSocket does not throw Exception in case it fails to establish GSSContext

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-821?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-821: -------------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1088795|https://bugzilla.redhat.com/show_bug.cgi?id=1088795] from NEW to CLOSED > SPNEGOSocket does not throw Exception in case it fails to establish GSSContext > ------------------------------------------------------------------------------ > > Key: SECURITY-821 > URL: https://issues.jboss.org/browse/SECURITY-821 > Project: PicketBox > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_1_5, Negotiation_2_2_7, Negotiation_2_3_0_Final > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: Negotiation_2_1_6, Negotiation_2_2_8, Negotiation_2_3_1_Final > > > Point of failure: https://github.com/wildfly/jboss-negotiation/blob/master/jboss-negotiatio... > Socket in mentioned versions log error and allow connection to be up. This is a cause of hangup in case of proxy lookup( atleast in EAP5 - JBPAPP-10748 ) > Code should terminate connection and throw exception upstream, in case login/logout(?) failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-821) SPNEGOSocket does not throw Exception in case it fails to establish GSSContext

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-821?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-821: -------------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1088793|https://bugzilla.redhat.com/show_bug.cgi?id=1088793] from NEW to CLOSED > SPNEGOSocket does not throw Exception in case it fails to establish GSSContext > ------------------------------------------------------------------------------ > > Key: SECURITY-821 > URL: https://issues.jboss.org/browse/SECURITY-821 > Project: PicketBox > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_1_5, Negotiation_2_2_7, Negotiation_2_3_0_Final > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: Negotiation_2_1_6, Negotiation_2_2_8, Negotiation_2_3_1_Final > > > Point of failure: https://github.com/wildfly/jboss-negotiation/blob/master/jboss-negotiatio... > Socket in mentioned versions log error and allow connection to be up. This is a cause of hangup in case of proxy lookup( atleast in EAP5 - JBPAPP-10748 ) > Code should terminate connection and throw exception upstream, in case login/logout(?) failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1829) Failing to connect to an unavailable member blocks all message sending

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1829?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1829: -------------------------------- Hmm, I assume you cause the split by shutting down the switch between sites A and B ? This means the TCP connection attempts will not return immediately, but wait until sock_conn_timeout kicks in. In case of a split, there needs to be traffic between the 2 partitions for some time, until the failure detection protocols and VERIFY_SUSPECT are done and we have 2 separate partitions. Note that even then there is some amount of traffic: the MERGE protocols always try to reach the other side. I don't think there's an easy fix to this. One thing you could try though is to replace FD with FD_ALL and remove VERIFT_SUSPECT. Both FD_SOCK and FD_ALL have only the coordinator doing VERIFY_SUSPECT work, whereas in FD, everyone does this. The basic issue though is that TCP is blocking and that's bad when a split occurs. With JGroups 4.0, we're moving to a non-blocking TCP impl and then this shouldn't be an issue anymore. Another suggestion is to use UDP instead of TCP. If you cannot switch because IP multicasting is not provided (e.g. in a cloud environment), you could still use UDP datagrams (UDP.ip_mcast=false). > Failing to connect to an unavailable member blocks all message sending > ---------------------------------------------------------------------- > > Key: JGRP-1829 > URL: https://issues.jboss.org/browse/JGRP-1829 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4.2 > Reporter: David Hotham > Assignee: Bela Ban > > Hi, > We're seeing a problem which appears to be caused by the TransferQueueBundler thread being blocked while it fails to connect to an unavailable member. > The setup we have is a cluster split across two sites: say, members 0 through 4 in site A and members 5 through 9 in site B. Initially the cluster is complete: everyone has the same view. The case that we're testing is: what happens when connectivity is lost between the sites? NB we're using TCP transport. > Obviously the expected result is that we'd get two sub-clusters, one in each site. But this doesn't always happen. Instead we sometimes see some members become singletons (that is, with only themselves in view). > What seems to be happening is something like this: > - When the cross-site link is cut, members in site A suspect members in site B (and vice versa). > - So in each site there's a broadcast of SUSPECT messages > - Now each of the members in site A tries to VERIFY_SUSPECT each of the members in site B > - Each such attempt blocks the TransferQueueBundler for two seconds (TCP's default sock_conn_timeout), because we can't contact any member in the other site > - But that introduces a delay for _all_ messages, not only for messages to the 'other' site > - If there are enough members in the 'other' site, we can easily get a large enough delay that HEARTBEAT (and then VERIFY_SUSPECT) messages start timing out between members in the same site > - At this point, members that ought to be able to see one another start to report that they cannot do so. > We've seen cases where a member becomes completely isolated - forming a singleton cluster - and does not recover. Unfortunately we don't have full trace from that run, so it's not clear why the cluster didn't eventually recover. I suspect that we're hitting something like JGRP-1493, in which delays sending messages (in that case, a delay when failing to get a physical address) caused the MergeKiller always to prevent merging. > It is highly undesirable that when a cluster contains several unavailable members, as in a partition between two sites, this should cause problems for members that can see one another. > Should all message sending really be blocked while failing to connect to an unavailable member? > This issue seems related also to JGRP-1815 which raises a similar question: should all message sending really be blocked while failing to find a physical address? > What do you think? > - do you agree that blocking message sending while attempting to connect to an unavailable member is undesirable? > - if so, what do you think the right fix is? If it's not too hard, we may be able to find time to take a look at implementing this ourselves. > - is there anything else we can do to help progress this issue? > We're using JGroups 3.4.2. I've attached the code fragment with which we configure the stack below. > Thanks for your help > David > {noformat} > stack.addProtocol((new TCP) > .setValue("enable_diagnostics", false) > .setValue("logical_addr_cache_max_size", 70) > .setValue("logical_addr_cache_expiration", 10000) > .setValue("physical_addr_max_fetch_attempts", 1) > .setValue("bind_addr", localAddr) > .setValue("bind_port", basePort) > .setValue("port_range", 0)) > val tcpping = new TCPPING > val jhosts = initialHosts map { addr => new IpAddress(addr.getHostAddress, basePort) } > tcpping.setInitialHosts(jhosts) > tcpping.setPortRange(0) > tcpping.setValue("return_entire_cache", true) > stack.addProtocol(tcpping) > .addProtocol(new MERGE3) > .addProtocol((new FD_SOCK) > .setValue("bind_addr", localAddr) > .setValue("client_bind_port", basePort + 1) > .setValue("start_port", basePort + 101) > .setValue("suspect_msg_interval", 1000)) > .addProtocol(new FD) > .addProtocol((new VERIFY_SUSPECT) > .setValue("timeout", 1000)) > .addProtocol((new NAKACK2) > .setValue("use_mcast_xmit", false)) > .addProtocol(new UNICAST3) > .addProtocol(new STABLE) > .addProtocol(new MFC) > .addProtocol(new SEQUENCER) > .addProtocol((new GMS) > .setValue("max_join_attempts", 3) > .setValue("use_delta_views", false)) > .addProtocol(new FRAG2) > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 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 April 2014