[JBoss JIRA] (WFCORE-616) Ensure end users cannot set the ""execute-for-coordinator" operation header via the HTTP interface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-616?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved WFCORE-616.
-------------------------------------
Resolution: Out of Date
Looks like the WFCORE-401 work corrected that
> Ensure end users cannot set the ""execute-for-coordinator" operation header via the HTTP interface
> --------------------------------------------------------------------------------------------------
>
> Key: WFCORE-616
> URL: https://issues.jboss.org/browse/WFCORE-616
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha19
> Reporter: Brian Stansberry
>
> The "execute-for-coordinator" header is used internally in domain-wide operation execution to indicate that a call is being made on behalf of the DC. End users should not be able to use it.
> Client calls that go through the native handling (including HTTP upgrade) have any such header stripped by ModelControllerClientOperationHandler.ExecuteRequestHandler. We need to do the same thing in the domain-http code for non-upgrade HTTP calls.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-624) Result transformation for composite op failures is broken
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-624?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-624:
------------------------------------
Labels: domain-mode (was: )
> Result transformation for composite op failures is broken
> ---------------------------------------------------------
>
> Key: WFCORE-624
> URL: https://issues.jboss.org/browse/WFCORE-624
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> CompositeOperationTransformer.CompositeResultTransformer works by analyzing the "step-x" entries in the remote response's "result" node, and then transforming that node.
> This breaks down when the failure actually occurs in the remote CompositeOperationHandler, as will be the case if the step refers to a resource or operation that is undefined on that node. In that case there is no "result" node with steps, just a top level failure.
> CompositeResultTransformer will actually add a "result" node with the expected error message in this case, but that basically works by luck. And the high level error message for the overall op will no be transformed.
> Possible improvements:
> 1) CompositeOperationHandler sets up a result node in this case, so CompositeResultTransformer can process it.
> 2) CompositeResultTransformer can try and fix up the top level error message as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-665) When host jvm name and server jvm name are same then the host jvm settings are ignored
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-665?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-665:
------------------------------------
Labels: domain-mode (was: )
> When host jvm name and server jvm name are same then the host jvm settings are ignored
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-665
> URL: https://issues.jboss.org/browse/WFCORE-665
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta5
> Environment: All
> Reporter: Jay SenSharma
> Assignee: Brian Stansberry
> Labels: domain-mode
>
> - If the "host.xml" has the following JVM name defined
> {code}
> <jvms>
> <jvm name="default">
> <heap size="200m" max-size="2000m"/>
> <permgen size="256m" max-size="256m"/>
> <jvm-options>
> <option value="-server"/>
> </jvm-options>
> </jvm>
> <jvm name="Test">
> <heap size="300m" max-size="2500m"/>
> <permgen size="128m" max-size="128m"/>
> </jvm>
> </jvms>
> {code}
> - If the server refers to the above JVM name as following:
> {code}
> <servers>
> <server name="server-one" group="main-server-group" auto-start="true">
> <jvm name="Test"/>
> </server>
> </servers>
> {code}
> - In above case when the server-one is booted that time it takes the value from "server-group" (in this case main-server-group) defined in the domain.xml
> {code}
> <server-groups>
> <server-group name="main-server-group" profile="full">
> <jvm name="default">
> <heap size="64m" max-size="512m"/>
> </jvm>
> {code}
> So the JVM settings defined for JVM name "Test" is overridden by server-group values:
> {code}
> 30201 jboss-modules.jar -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on -D[Server:server-one] -XX:PermSize=128m -XX:MaxPermSize=128m -Xms64m -Xmx512m -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Djboss.home.dir=/wildfly-9.0.0.CR1-SNAPSHOT -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.log.dir=/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/log -Djboss.server.temp.dir=/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/tmp -Djboss.server.data.dir=/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/data -Dlogging.configuration=file:/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/data/logging.properties
> {code}
> *NOTICE* the JVM runtime value is -Xms64m -Xmx512m, where as it was supposed to be -Xms300m -Xmx2500m as that is the "Test" jvm setting.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-8340) Resuming a batch job after server resume requires the anonymous identity to have RunAsPrincipalPermission of the original user
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-8340?page=com.atlassian.jira.plugin.... ]
James Perkins moved JBEAP-9493 to WFLY-8340:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8340 (was: JBEAP-9493)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Batch
Security
(was: Batch)
(was: Security)
> Resuming a batch job after server resume requires the anonymous identity to have RunAsPrincipalPermission of the original user
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8340
> URL: https://issues.jboss.org/browse/WFLY-8340
> Project: WildFly
> Issue Type: Bug
> Components: Batch, Security
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
> Attachments: jbeap9452reproducer.zip
>
>
> - Batch job is submitted by user A
> - While the job is running, the server gets suspended
> - When user B calls the {{resume}} operation, the Batch execution is attempted to be restarted. However, this only works if anonymous identity has the permission {{org.wildfly.security.auth.permission.RunAsPrincipalPermission}} for user A, which is not the case in the default configuration.
> I find this a UX issue because you have to add a special permission to make this work when it should work out-of-the-box, and also one might not want to give this permission to {{anonymous}} because it could be potentially abused in other places.
> {noformat}
> 14:59:53,729 TRACE [org.wildfly.security] (management-handler-thread - 4) Permission mapping: identity [anonymous] with roles [] implies ("org.wildfly.security.auth.permission.RunAsPrincipalPermission" "user1") = false
> 14:19:53,842 ERROR [org.wildfly.extension.batch] (management-handler-thread - 4) WFLYBATCH000016: Failed to restart execution 1 for job server-suspend on deployment server-suspend.war: org.wildfly.security.authz.AuthorizationFailureException: ELY01088: Attempting to run as "user1" authorization operation failed
> at org.wildfly.security.auth.server.SecurityIdentity.createRunAsIdentity(SecurityIdentity.java:628)
> at org.wildfly.security.auth.server.SecurityIdentity.createRunAsIdentity(SecurityIdentity.java:603)
> at org.wildfly.extension.batch.jberet.deployment.JobOperatorService$BatchJobServerActivity.privilegedRunAs(JobOperatorService.java:520)
> at org.wildfly.extension.batch.jberet.deployment.JobOperatorService$BatchJobServerActivity.restartStoppedJobs(JobOperatorService.java:495)
> at org.wildfly.extension.batch.jberet.deployment.JobOperatorService$BatchJobServerActivity.resume(JobOperatorService.java:430)
> at org.jboss.as.server.suspend.SuspendController.resume(SuspendController.java:127)
> at org.jboss.as.server.operations.ServerResumeHandler$1$1.handleResult(ServerResumeHandler.java:79)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1493)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1475)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1437)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1410)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1284)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:856)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:842)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:748)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1388)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:258)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-255) Boot time only system properties should not modify the runtime only the model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-255?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-255:
------------------------------------
Labels: domain-mode (was: )
> Boot time only system properties should not modify the runtime only the model
> -----------------------------------------------------------------------------
>
> Key: WFCORE-255
> URL: https://issues.jboss.org/browse/WFCORE-255
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: James Perkins
> Assignee: James Perkins
> Labels: domain-mode
>
> The three properties {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} are allowed to be overridden for servers. They cannot be set as a system-property resource, but can be overridden via {{JAVA_OPTS}} or the command line. For a domain server these values need to be allowed to be set as a {{boot-time=true}} system property.
> The {{add}}, {{write-attribute}} and {{remove}} operations should not modify the runtime, but should modify the model. It's debatable whether the server should be put in a {{restart-required}} state. Currently similar resources do _not_ set the server state to {{restart-required}}. For now we should stick with the same state.
> {code}
> [domain@localhost:9999 /] /host=master/system-property=jboss.server.log.dir:add(boot-time=true,value="/var/log")
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {
> "server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line",
>
> "rolled-back" => true
> }},
> "server-two" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line",
> "rolled-back" => true
> }}
> }}}}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-199) Domain graceful shutdown may attempt to use an AbstractMessageHandler that is shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-199?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-199:
------------------------------------
Labels: domain-mode (was: )
> Domain graceful shutdown may attempt to use an AbstractMessageHandler that is shutdown
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-199
> URL: https://issues.jboss.org/browse/WFCORE-199
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha10
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> ManagedServer during shutdown tries to send a "shutdown" op to the remote server, triggering a graceful suspend.
> Problem is, the TransactionalProtocolClient it uses is using a ManagementChannelHandler that may have been shut down. The service that controls the lifecycle of the ManagementChannelHandler (i.e. ManagementChannelOpenListenerService) is written to ensure that it isn't shutdown open until incoming requests complete, but there is nothing preventing shutdown when client uses are desired.
> The specific area where this can be a problem is the assert !shutdown at
> https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/jav...
> One possible solution is to distinguish locally initiated active operations from remote ones. AIUI the goal is to reject further remote ones.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months