[JBoss JIRA] (WFLY-2412) security realms and ldap connections incorrectly hidden by default in domain mode.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------
Darran Lofthouse <darran.lofthouse(a)redhat.com> made a comment on [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930]
In that case probably a bad resource definition exposing those resources at domain level.
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
> Key: WFLY-2412
> URL: https://issues.jboss.org/browse/WFLY-2412
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain@localhost:9990 /] :whoami(verbose=true)
> {
> "outcome" => "success",
> "result" => {
> "identity" => {
> "username" => "$local",
> "realm" => "ManagementRealm"
> },
> "mapped-roles" => ["SuperUser"]
> }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain@localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[
> (\"core-service\" => \"management\"),
> (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.
--
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, 8 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1675 at 10/30/13 12:00 PM:
-----------------------------------------------------------
Tried to replicate the stress test in JGroups ({{RemoteGetStressTest}} is attached). With 500 threads, the tests completes between 60 and 90 seconds. This is with a random delay de-serializing the BigObject between 1 and 10 ms, and with a DISCARD up-rate of 20%.
If {{USE_SLEEPS}} is changed to false, the test finishes within a few seconds (between 2 and 5 secs). This is with an OOB pool of min=1/max=5/no-queue.
The delaying and discarding certainly slows things down, but I never experienced a deadlock.
was (Author: belaban):
Tried to replicate the stress test in JGroups (RemoteGetStressTest ia attached). With 500 threads, the tests completes within 60 and 90 seconds. This is with a random delay de-serializing the BigObject between 1 and 10 ms, and with a DISCARD up-rate of 20%.
If {{USE_SLEEPS}} is changed to false, the test finishes within a few second (between 2 and 5 secs). This is with an OOB pool of min=1/max=5/no-queue.
The delaying and discarding certainly slows things downm, but I never experience a deadlock.
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: RemoteGetStressTest.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
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, 8 months
[JBoss JIRA] (WFLY-882) Improve error message for bad/incomplete XML in deployment scanner
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-882?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-882:
------------------------------
Summary: Improve error message for bad/incomplete XML in deployment scanner (was: Deploying dynamic VDB with invalid XML will cause incomprehensible error)
Labels: jug_hackathon_candidate (was: )
We could improve the error by saying something like "blah.xml is not well-formed waiting in case it is an incomplete copy."
> Improve error message for bad/incomplete XML in deployment scanner
> ------------------------------------------------------------------
>
> Key: WFLY-882
> URL: https://issues.jboss.org/browse/WFLY-882
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Filip Nguyen
> Priority: Trivial
> Labels: jug_hackathon_candidate
> Attachments: loop-vdb.xml
>
>
> Deploying VDB with invalid XML (closed translator tag). Causes following error:
> [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015009: Scan found incompletely copied file content for deployment standalone/deployments/loop-vdb.xml. Deployment changes will not be processed until all content is complete.
--
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, 8 months
[JBoss JIRA] (WFLY-2412) security realms and ldap connections incorrectly hidden by default in domain mode.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> made a comment on [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930]
There are no domain level security realm resources. You need to prefix that address with /host=<name of a host>.
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
> Key: WFLY-2412
> URL: https://issues.jboss.org/browse/WFLY-2412
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain@localhost:9990 /] :whoami(verbose=true)
> {
> "outcome" => "success",
> "result" => {
> "identity" => {
> "username" => "$local",
> "realm" => "ManagementRealm"
> },
> "mapped-roles" => ["SuperUser"]
> }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain@localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[
> (\"core-service\" => \"management\"),
> (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.
--
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, 8 months
[JBoss JIRA] (WFLY-2412) security realms and ldap connections incorrectly hidden by default in domain mode.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930] from ASSIGNED to CLOSED
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
> Key: WFLY-2412
> URL: https://issues.jboss.org/browse/WFLY-2412
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain@localhost:9990 /] :whoami(verbose=true)
> {
> "outcome" => "success",
> "result" => {
> "identity" => {
> "username" => "$local",
> "realm" => "ManagementRealm"
> },
> "mapped-roles" => ["SuperUser"]
> }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain@localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[
> (\"core-service\" => \"management\"),
> (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.
--
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, 8 months
[JBoss JIRA] (WFLY-2267) Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-2267:
------------------------------------
Did you originally change from NON_XA to FULL_XA? As far as I can tell, we default to NON_XA, so I am curious what led you to use FULL_XA mode?
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-2267
> URL: https://issues.jboss.org/browse/WFLY-2267
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
> Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
> Reporter: Jari Juslin
> Assignee: Scott Marlow
> Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
> * @author Jari Juslin, zds(a)ecolane.com
> */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
> @PersistenceContext(unitName = "persistence_context2")
> protected EntityManager entityManager;
>
> @POST
> public String manifestArjunaBug() {
> BugReproEntity entry = new BugReproEntity();
> entityManager.persist(entry);
>
> entry.setHasChanges(true);
>
> return "Success\n";
> }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
> private Integer id;
> private boolean hasChanges;
> public BugReproEntity() {
> }
> @Id
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Column(name="id")
> public Integer getId() {
> return id;
> }
> public void setId(Integer id) {
> this.id = id;
> }
> @Column(name="has_changes")
> public boolean getHasChanges() {
> return hasChanges;
> }
> public void setHasChanges(boolean hasChanges) {
> this.hasChanges = hasChanges;
> }
> }
> Infinispan config block on standalone.xml:
> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate">
> <local-cache name="entity">
> <transaction mode="FULL_XA"/>
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> <indexing index="LOCAL">
> <property name="hibernate.search.default.directory_provider">
> ram
> </property>
> </indexing>
> </local-cache>
> ...
> </cache-container>
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
> <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
> <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
> <driver>mysql</driver>
> <security>
> <user-name>*******</user-name>
> <password>*******</password>
> </security>
> </datasource>
> <drivers>
> <driver name="mysql" module="com.mysql">
> <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
> </driver>
> </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.
--
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, 8 months
[JBoss JIRA] (WFLY-2412) security realms and ldap connections incorrectly hidden by default in domain mode.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2412:
-----------------------------------
Parent: WFLY-490
Issue Type: Sub-task (was: Bug)
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
> Key: WFLY-2412
> URL: https://issues.jboss.org/browse/WFLY-2412
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain@localhost:9990 /] :whoami(verbose=true)
> {
> "outcome" => "success",
> "result" => {
> "identity" => {
> "username" => "$local",
> "realm" => "ManagementRealm"
> },
> "mapped-roles" => ["SuperUser"]
> }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain@localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[
> (\"core-service\" => \"management\"),
> (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.
--
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, 8 months