[JBoss JIRA] (WFLY-4253) CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4253?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski commented on WFLY-4253:
------------------------------------------
PB PR has been merged,
> CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-4253
> URL: https://issues.jboss.org/browse/WFLY-4253
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.2.0.Final
> Environment: Java 1.8.0_25
> Reporter: Rostyslav Smirnov
> Assignee: Bartosz Baranowski
>
> org.jboss.security.identity.extensions.CredentialIdentityFactory.NULL_IDENTITY does not get initialized to an empty identity due to initialization method returning a reference to NULL_IDENTITY, which has not initialized yet, resulting in null pointer. This causes NullPointerException in org.jboss.security.SecurityContextUtil.clearIdentities() and org.jboss.security.SecurityContextUtil.getIdentities() methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JGRP-1855) FD_HOST: host failure detection protocol
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1855?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1855:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1113220|https://bugzilla.redhat.com/show_bug.cgi?id=1113220] from VERIFIED to CLOSED
> FD_HOST: host failure detection protocol
> ----------------------------------------
>
> Key: JGRP-1855
> URL: https://issues.jboss.org/browse/JGRP-1855
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.5, 3.5
>
>
> A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host.
> Features are:
> * Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL)
> ** A structure keeps track of hosts (IP addresses) and members on those hosts
> *** Example
> ||192.168.1.2||192.168.1.3||192.168.1.5||
> |A,B,C|D,E,F|X,Y,Z|
> * We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc
> * The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}).
> * When an entire host is suspected, we suspect *all* cluster members on it
> ** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1898:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from VERIFIED to CLOSED
> FD_HOST many false suspect with Full GC
> ---------------------------------------
>
> Key: JGRP-1898
> URL: https://issues.jboss.org/browse/JGRP-1898
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.5.1
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Fix For: 3.4.7, 3.5.2, 3.6.1
>
> Attachments: FD_HOSTTest.java, test-fdhost.zip
>
>
> Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop.
> {code}
> for (h: hosts) { ping_and_update_timestamp(host) }
> current = System.currentTimeMillis();
> for (h: hosts) { compare current and (ping_timestmp + timeout) }
> {code}
> Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects.
> For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation.
> To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-504) RBAC does not let server-group scoped roles read all hosts
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-504?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-504:
------------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1178810|https://bugzilla.redhat.com/show_bug.cgi?id=1178810] from POST to MODIFIED
> RBAC does not let server-group scoped roles read all hosts
> ----------------------------------------------------------
>
> Key: WFCORE-504
> URL: https://issues.jboss.org/browse/WFCORE-504
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha15
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha16
>
>
> The RBAC implementation is not allowing a server-group scoped role to read resources in the host=* tree unless one of these is true:
> 1) the host only contains a server mapped to the server group
> 2) the host doesn't contain any servers.
> This is consistent with handling of other "mappable" things but is contrary to the docs, which declare
> "In addition to these privileges, users in a server-group scoped role will have non-sensitive read privileges (equivalent to the Monitor role) for resources other than those listed above."
> but don't list these host resources.
> It's also unintuitive, as the s-g-s-r is actually allowed to add a server on the host, but can't read the other host resources before doing so.
> Also, asking the DC for the list of host names will include the host, but trying to read its root resource will result in a NoSuchResourceException.
> The issue dates back to 8.0, but recent changes to the console have resulted in this breaking console behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-520) Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFCORE-520?page=com.atlassian.jira.plugin... ]
Brad Maxwell commented on WFCORE-520:
-------------------------------------
[~ctomc] ah yes, it looks like this version below. Somewhere I thought I saw alpha 15, but it looks like my build from master was using Alpha9
<groupId>org.wildfly</groupId>
<artifactId>wildfly-parent</artifactId>
<version>9.0.0.Alpha2-SNAPSHOT</version>
<version.org.wildfly.core>1.0.0.Alpha9</version.org.wildfly.core>
> Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
> --------------------------------------------------------------------------------
>
> Key: WFCORE-520
> URL: https://issues.jboss.org/browse/WFCORE-520
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha9
> Reporter: Brad Maxwell
> Assignee: Brian Stansberry
> Attachments: JMXTest.java, server.log
>
>
> A NullPointerException randomly occurs in org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) when getMBeanCount is called over and over.
> See attached server.log and reproducer
> {noformat}
> 00:16:01,315 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-2) WFLYCTL0013: Operation ("check-default-resource-access") failed - address: ([
> ("core-service" => "management"),
> ("service" => "management-operations"),
> ("active-operation" => "-1652526387")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:1136) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:130) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$CheckResourceAccessHandler.execute(ReadResourceDescriptionHandler.java:467) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:700) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:328) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:197) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:51) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:105) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:154) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:561) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.getMBeanCount(BlockingNotificationMBeanServer.java:143) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:655)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-520) Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFCORE-520?page=com.atlassian.jira.plugin... ]
Brad Maxwell updated WFCORE-520:
--------------------------------
Affects Version/s: 1.0.0.Alpha9
(was: 1.0.0.Alpha15)
> Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
> --------------------------------------------------------------------------------
>
> Key: WFCORE-520
> URL: https://issues.jboss.org/browse/WFCORE-520
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha9
> Reporter: Brad Maxwell
> Assignee: Brian Stansberry
> Attachments: JMXTest.java, server.log
>
>
> A NullPointerException randomly occurs in org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) when getMBeanCount is called over and over.
> See attached server.log and reproducer
> {noformat}
> 00:16:01,315 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-2) WFLYCTL0013: Operation ("check-default-resource-access") failed - address: ([
> ("core-service" => "management"),
> ("service" => "management-operations"),
> ("active-operation" => "-1652526387")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:1136) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:130) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$CheckResourceAccessHandler.execute(ReadResourceDescriptionHandler.java:467) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:700) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:328) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:197) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:51) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:105) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:154) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:561) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.getMBeanCount(BlockingNotificationMBeanServer.java:143) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:655)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (SECURITY-640) Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-640?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-640:
--------------------------------------------------
Josef Cacek <jcacek(a)redhat.com> changed the Status of [bug 1085500|https://bugzilla.redhat.com/show_bug.cgi?id=1085500] from POST to ON_QA
> Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-640
> URL: https://issues.jboss.org/browse/SECURITY-640
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Environment: Active Directory Winwos 2003, Client Machine windows XP, Jboss Server Machine Window XP and Jboss 6.1
> Reporter: Hrishi Salvi
> Assignee: Derek Horton
> Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2
>
>
> We are trying to configure the single sign on using jboss negotiation.
> We are able to login successfully if the user is present in active directory.
> But in case if user is not present in active directory users, it throw 401 error page.
> Instead of 401 we want user to access login form and authenticate user using different login module.
> In our case we have login page we authenticate user on that page.
> If we receive user credentials we login the user without asking for password.
> Now if the user credentials are not received then we want user to open login form present
> on login page, but before that is throws 401 error.
> We have configure the login-config.xml, web.xml and jboss-web.xml as per the documentation.
> Also defined
> <web-resource-collection>
> <web-resource-name>Restricted</web-resource-name>
> <url-pattern>/Request</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> in web.xml
> Our application is access through Request servlet.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months