[JBoss JIRA] (WFCORE-1028) Poor handling of invalid roles
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1028:
----------------------------------------
Summary: Poor handling of invalid roles
Key: WFCORE-1028
URL: https://issues.jboss.org/browse/WFCORE-1028
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.0.CR5
Reporter: Brian Stansberry
A CLI request with an invalid value in the "roles" header results in improper behavior:
{code}
[domain@localhost:9990 /] /host=*:read-resource{roles=slave-monitor}
{
"outcome" => "failed",
"result" => [],
"rolled-back" => true
}
{code}
The op should fail because the role doesn't exist, but there is no failure-description.
The following is dumped in the HC log:
{code}
[Host Controller] 12:22:12,314 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve") failed - address: ([]): java.lang.IllegalArgumentException: WFLYCTL0327: Unknown role 'slave-monitor'
[Host Controller] at org.jboss.as.controller.access.rbac.StandardRoleMapper.canRunAs(StandardRoleMapper.java:95)
[Host Controller] at org.jboss.as.controller.access.rbac.RunAsRoleMapper.mapRoles(RunAsRoleMapper.java:143)
[Host Controller] at org.jboss.as.controller.access.rbac.RunAsRoleMapper.mapRoles(RunAsRoleMapper.java:71)
[Host Controller] at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:109)
[Host Controller] at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:91)
[Host Controller] at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:99)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1753)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1651)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:833)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.readResource(OperationContextImpl.java:818)
[Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ModelAddressResolver.execute(GlobalOperationHandlers.java:402)
[Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ModelAddressResolver.execute(GlobalOperationHandlers.java:306)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
[Host Controller] at java.security.AccessController.doPrivileged(Native Method)
[Host Controller] at javax.security.auth.Subject.doAs(Subject.java:422)
[Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Host Controller] at java.lang.Thread.run(Thread.java:745)
[Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1027) Inconsistent read-resource results with host scoped roles
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-1027:
----------------------------------
Summary: Inconsistent read-resource results with host scoped roles
Key: WFCORE-1027
URL: https://issues.jboss.org/browse/WFCORE-1027
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.0.CR5
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 2.0.0.CR6
Setting up host scoped roles as follows https://gist.github.com/heiko-braun/0dc810ed04db8739defd there are inconsistent results in the filtering. When using a role which only selects the master there is no access-control response header showing the filtered resources, and the slave wrongly appears in the results:
{code}
[domain@localhost:9990 /] /host=*:read-resource{roles=master-monitor}
{
"outcome" => "success",
"result" => [
{
"address" => [("host" => "master")],
"outcome" => "success",
"result" => {
"directory-grouping" => "by-server",
"domain-controller" => {"local" => {}},
"management-major-version" => 4,
"management-micro-version" => 0,
"management-minor-version" => 0,
"master" => true,
"name" => "master",
"namespaces" => [],
"organization" => undefined,
"product-name" => "WildFly Core",
"product-version" => "2.0.0.CR6-SNAPSHOT",
"release-codename" => "Kenny",
"release-version" => "2.0.0.CR6-SNAPSHOT",
"schema-locations" => [],
"core-service" => {
"host-environment" => undefined,
"platform-mbean" => undefined,
"management" => undefined,
"discovery-options" => undefined,
"ignored-resources" => undefined,
"patching" => undefined,
"module-loading" => undefined
},
"extension" => {"org.jboss.as.jmx" => undefined},
"interface" => {
"management" => undefined,
"public" => undefined,
"unsecure" => undefined
},
"jvm" => {"default" => undefined},
"path" => undefined,
"server" => {
"server-one" => undefined,
"server-two" => undefined,
"server-three" => undefined
},
"server-config" => {
"server-one" => undefined,
"server-two" => undefined,
"server-three" => undefined
},
"socket-binding-group" => undefined,
"subsystem" => {"jmx" => undefined},
"system-property" => undefined
}
},
{
"address" => [("host" => "localhost")],
"outcome" => "success",
"result" => undefined
}
]
}
{code}
When using a role that only selects the slave we get a proper access-control header
{code}
[domain@localhost:9990 /] /host=*:read-resource{roles=slave-maintainer}
{
"outcome" => "success",
"result" => [{
"address" => [("host" => "localhost")],
"outcome" => "success",
"result" => undefined
}],
"response-headers" => {"access-control" => [{
"absolute-address" => [],
"relative-address" => [],
"filtered-children-types" => ["host"]
}]}
{code}
The same output on master with WFCORE-994 applied:
{code}
[domain@localhost:9990 /] /host=*:read-resource{roles=slave-maintainer}
{
"outcome" => "success",
"result" => [{
"address" => [("host" => "slave")],
"outcome" => "success",
"result" => {
"directory-grouping" => "by-server",
"domain-controller" => {"remote" => {
"protocol" => undefined,
"port" => undefined,
"host" => undefined,
"username" => undefined,
"ignore-unused-configuration" => undefined,
"admin-only-policy" => undefined,
"security-realm" => "ManagementRealm"
}},
"management-major-version" => 4,
"management-micro-version" => 0,
"management-minor-version" => 0,
"master" => false,
"name" => "slave",
"namespaces" => [],
"organization" => undefined,
"product-name" => undefined,
"product-version" => undefined,
"release-codename" => "Kenny",
"release-version" => "2.0.0.CR6-SNAPSHOT",
"schema-locations" => [],
"core-service" => {
"host-environment" => undefined,
"platform-mbean" => undefined,
"management" => undefined,
"discovery-options" => undefined,
"ignored-resources" => undefined,
"patching" => undefined,
"module-loading" => undefined
},
"extension" => {"org.jboss.as.jmx" => undefined},
"interface" => {
"management" => undefined,
"public" => undefined,
"unsecure" => undefined
},
"jvm" => {"default" => undefined},
"path" => undefined,
"server" => {
"server-one" => undefined,
"server-two" => undefined
},
"server-config" => {
"server-one" => undefined,
"server-two" => undefined
},
"socket-binding-group" => undefined,
"subsystem" => {"jmx" => undefined},
"system-property" => undefined
}
}],
"response-headers" => {"access-control" => [{
"absolute-address" => [],
"relative-address" => [],
"filtered-children-types" => ["host"]
}]}
}
{code}
master-monitor should behave the same as slave-maintainer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (LOGMGR-123) TCP reconnect will only attempt to reconnect once
by James Perkins (JIRA)
James Perkins created LOGMGR-123:
------------------------------------
Summary: TCP reconnect will only attempt to reconnect once
Key: LOGMGR-123
URL: https://issues.jboss.org/browse/LOGMGR-123
Project: JBoss Log Manager
Issue Type: Bug
Reporter: James Perkins
Assignee: James Perkins
The same thread used in an attempt to start a reconnect. This means a reconnect will only be attempted and reconnected once. If another disconnect happens starting the reconnect fails as the same thread cannot be restarted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (LOGMGR-122) Syslog handler is not generating correct timestamp format
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-122?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-122:
--------------------------------------
Thanks for finding this! I've released a 2.0.1.Final version which is compatible with WildFly 9 so you could just replace the module.
> Syslog handler is not generating correct timestamp format
> ---------------------------------------------------------
>
> Key: LOGMGR-122
> URL: https://issues.jboss.org/browse/LOGMGR-122
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.0.0.Final
> Environment: Wildfly 9.0.1.Final, Oracle JRE 1.8.0_11, CentOS 6
> Reporter: Ricardo Kagawa
> Assignee: James Perkins
> Fix For: 1.4.4.Final, 1.5.5.Final, 2.0.1.Final, 2.1.0.Beta1
>
>
> The Syslog handler is outputting an extra zero before the month in the header timestamp for RFC5424, specifically for October.
> Checking [Github|https://github.com/jboss-logging/jboss-logmanager/blob/master/src/...], I have noticed that the month number is tested for double digit before being offset, so a zero is added for October (month 9 for java.util.Calendar), then offset for proper display (month "10" for ISO8601), resulting in a three-digit month ("010").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1025) ManagementRequestContext executeAsync hides RejectedExecutionException
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1025:
----------------------------------------
Summary: ManagementRequestContext executeAsync hides RejectedExecutionException
Key: WFCORE-1025
URL: https://issues.jboss.org/browse/WFCORE-1025
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.0.CR5
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.0.CR6
The impl of ManagementRequestContext executeAsync catches RejectedExecutionException and doesn't notify the calling thread. The handling itself seems ok (call failed on the result handler and send a failure response to the client), but not notifying the caller is problematic. There are a number of cases where the caller thread waits for a latch to be tripped, with the async task tripping. If the latch never trips, the caller thread will block forever. The testsuite hang at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=71233&buildTyp... looks to be a case of this, with a server not stopping due to this:
{code}
"Remoting "master:main-one:MANAGEMENT" task-13" #55 prio=5 os_prio=0 tid=0xc6c3bc00 nid=0x19d9 waiting on condition [0xc215c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xddbb4aa0> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.sendResponse(TransactionalProtocolOperationHandler.java:540)
at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.failed(TransactionalProtocolOperationHandler.java:377)
- locked <0xddbb2300> (a org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext)
at org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl$2.handleFailed(ActiveOperationSupport.java:350)
at org.jboss.threads.AsyncFutureTask$Reg.run(AsyncFutureTask.java:60)
at org.jboss.as.protocol.mgmt.ActiveOperationSupport$1.execute(ActiveOperationSupport.java:55)
at org.jboss.threads.AsyncFutureTask.safeExecute(AsyncFutureTask.java:169)
at org.jboss.threads.AsyncFutureTask.setFailed(AsyncFutureTask.java:162)
at org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl.access$400(ActiveOperationSupport.java:295)
at org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl$1.failed(ActiveOperationSupport.java:315)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2.executeAsync(AbstractMessageHandler.java:333)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2.executeAsync(AbstractMessageHandler.java:315)
at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.handleRequest(TransactionalProtocolOperationHandler.java:144)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:252)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:123)
at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
The RejectedExecutionException indicates a thread pool has been shutdown before the response has gone out. Ideally we would prevent that (for which I've recently filed a JIRA) but in any case we should make this more robust.
I think having executeAsync return a boolean should suffice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-934) Persistence unit tests - DB2 default schema not specified
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-934?page=com.atlassian.jira.plugin... ]
Petr Široký reassigned DROOLS-934:
----------------------------------
Assignee: Petr Široký (was: Mark Proctor)
Resolution: Done
Fixed by Tibor and merged into 6.3.x and master branched.
> Persistence unit tests - DB2 default schema not specified
> ---------------------------------------------------------
>
> Key: DROOLS-934
> URL: https://issues.jboss.org/browse/DROOLS-934
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Tibor Zimányi
> Assignee: Petr Široký
> Priority: Minor
> Fix For: 6.4.x
>
>
> Unit tests in drools-persistence-jpa don't work on DB2 database system because there isn't specified DB schema in tests.
> Things needed to be done:
> - hibernate.default_schema property set in persistence.xml
> - schema should be set in PersistenceUtil, when creating data source
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-934) Persistence unit tests - DB2 default schema not specified
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-934?page=com.atlassian.jira.plugin... ]
Petr Široký edited comment on DROOLS-934 at 10/1/15 11:07 AM:
--------------------------------------------------------------
Fixed by Tibor and merged into 6.3.x and master branches.
was (Author: psiroky-redhat.com):
Fixed by Tibor and merged into 6.3.x and master branched.
> Persistence unit tests - DB2 default schema not specified
> ---------------------------------------------------------
>
> Key: DROOLS-934
> URL: https://issues.jboss.org/browse/DROOLS-934
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Tibor Zimányi
> Assignee: Petr Široký
> Priority: Minor
> Fix For: 6.4.x
>
>
> Unit tests in drools-persistence-jpa don't work on DB2 database system because there isn't specified DB schema in tests.
> Things needed to be done:
> - hibernate.default_schema property set in persistence.xml
> - schema should be set in PersistenceUtil, when creating data source
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months