May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1497) RBAC roles scoped to addresses that match a regex

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1497?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1497: ------------------------------------------ https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... has my work on this. On the wildfly-dev list discussion the consensus was to go in a different direction in terms of how the role is configured, and I didn't have time to get to that. But the branch ^^^ is a reasonable starting point. > RBAC roles scoped to addresses that match a regex > ------------------------------------------------- > > Key: WFCORE-1497 > URL: https://issues.jboss.org/browse/WFCORE-1497 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Host scoped roles and server group scoped roles work via a constraint that checks the address being manipulated against a calculated group of allowed addresses. That calculation is complex in the server group and host cases to account for the complex semantics of those kinds of scoping while requiring very little config from the user, but we could also have a similar kind of scoping that requires more config from the user but is also more flexible. The user configures one or more regex strings, and any address (or canonical mbean object name) that matches meets the constraint. > Example, a "log-maintainer" role that gets Maintainer privileges for the logging subsystem but is Monitor for everything else: > {code} > <pattern-scoped-role name="log-maintainer" base-role="Maintainer> > <patterns> > <pattern value="(/profile=[^/]+)?/subsystem=logging(/.*)?"/> > </patterns> > </pattern-scoped-role> > {code} > I use logging as an example as it's a use case I can imagine easily enough -- a server is largely locked down but tweaks to logging are allowed to allow diagnostic data to be gathered. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2734) ParallelBootOperationContext should add "foreign" steps to the main context

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2734?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2734: ------------------------------------------ https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... shows this, although I'm not sure supporting this a great idea. OTOH people may try and do it regardless so this at least provides a better shot at correct behavior. > ParallelBootOperationContext should add "foreign" steps to the main context > --------------------------------------------------------------------------- > > Key: WFCORE-2734 > URL: https://issues.jboss.org/browse/WFCORE-2734 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The ParallelBootOperationContext addStep impl always adds steps for the same stage to its own queue. It should check the address of those steps and if not for its own subsystem it should add them to the main context's queue. This will allow subsystem A to add steps that affect subsystem B safe in the knowledge they will execute after completion of the parallel part of B's execution. > In Stage.MODEL addition of such steps for Stage.RUNTIME should be rejected. Such steps will not execute in any reasonable order vs the non-foreign steps that B itself will add. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2631) UnsupportedOperationException for {allow-resource-service-restart=true} for inner attributes in Elytron subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2631?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2631: ---------------------------------------- Assignee: Tomas Hofman (was: Brian Stansberry) > UnsupportedOperationException for {allow-resource-service-restart=true} for inner attributes in Elytron subsystem > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2631 > URL: https://issues.jboss.org/browse/WFCORE-2631 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 3.0.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Tomas Hofman > Priority: Critical > > In case when resource in Elytron subsystem includes {{attributes}} which have set {{"restart-required" => "resource-services"}} and includes also some {{"value-type"}} for inner attributes, then flag {{allow-resource-service-restart=true}} cannot be used correctly for those inner attributes. > See example: > {code} > /subsystem=elytron/properties-realm=ManagementRealm:write-attribute(name=users-properties.plain-text,value=true) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > This command set server to {{"reload-required"}} state. However In case, when flag {{allow-resource-service-restart=true}} is set, then UnsupportedOperationException is returned for the same command. > {code} > /subsystem=elytron/properties-realm=ManagementRealm:write-attribute(name=users-properties.plain-text,value=true){allow-resource-service-restart=true} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.UnsupportedOperationException", > "rolled-back" => true > } > {code} > In case when operation set server to {{"process-state" => "reload-required"}} then flag {{allow-resource-service-restart=true}} should be supported. Otherwise whole server needs to be reloaded. > Exception thrown to server log for mentioned above CLI command: > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("write-attribute") failed - address: ([ > ("subsystem" => "elytron"), > ("properties-realm" => "ManagementRealm") > ]): java.lang.UnsupportedOperationException > at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:145) > at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:126) > at org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:72) > at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1397) > 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:263) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229) > 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:287) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8676) Unignore RunAsEjbMdbTestCase and RemoteIdentityTestCase for the Elytron profile

by Farah Juma (JIRA)

Farah Juma created WFLY-8676: -------------------------------- Summary: Unignore RunAsEjbMdbTestCase and RemoteIdentityTestCase for the Elytron profile Key: WFLY-8676 URL: https://issues.jboss.org/browse/WFLY-8676 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Farah Juma Assignee: Farah Juma Since WFLY-8414 has been fixed, these tests now pass with the Elytron profile enabled. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8677) Unignore RunAsEjbMdbTestCase and RemoteIdentityTestCase for the Elytron profile

by Farah Juma (JIRA)

Farah Juma created WFLY-8677: -------------------------------- Summary: Unignore RunAsEjbMdbTestCase and RemoteIdentityTestCase for the Elytron profile Key: WFLY-8677 URL: https://issues.jboss.org/browse/WFLY-8677 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Farah Juma Assignee: Farah Juma Since WFLY-8414 has been fixed, these tests now pass with the Elytron profile enabled. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1632) Server processing request isn't stopped immediately but waits for request processing to finish

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1632?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1632: ------------------------------------------ The WFCORE-1299 fix to add (correctly so) proper shutdown handling to WorkerService is what led to server shutdown blocking until in-flight requests complete. > Server processing request isn't stopped immediately but waits for request processing to finish > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1632 > URL: https://issues.jboss.org/browse/WFCORE-1632 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, IO, Server > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Critical > Original Estimate: 1 day > Remaining Estimate: 1 day > > When stopping server which is processing request, it terminates the connection from the client but doesn't stop the request processing as such. > After debugging and searching when the issue appeared I've found out that the issue was introduced with this commit: [https://github.com/wildfly/wildfly-core/commit/7304c019705c5f7ec0378e1c51...] > Steps to reproduce: > 1) start EAP server with deployed app from attachment > 2) create request to long running application: {{curl -i http://127.0.0.1:8080/long-running-servlet/HeavyProcessing?duration=25000}} > 3) stop server (you can do it even gracefully) using {{./jboss-cli.sh -c ":shutdown(timeout=1)"}} > See that server is stopped after 25 seconds since request from step 2 was issued, as that is duration of the request processing requested by param duration, instead of being terminated after 1 second. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8570) Get rid of use of ServiceVerificationHandler

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-8570?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-8570: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9932 (was: https://issues.jboss.org/browse/WFLY-8570) > Get rid of use of ServiceVerificationHandler > -------------------------------------------- > > Key: WFLY-8570 > URL: https://issues.jboss.org/browse/WFLY-8570 > Project: WildFly > Issue Type: Task > Components: EJB, Security > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > ServiceVerificationHandler was deprecated 30 months ago. EJB and picketlink subsystems are still using it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8675) Get rid of use of ServiceVerificationHandler

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-8675: -------------------------------------- Summary: Get rid of use of ServiceVerificationHandler Key: WFLY-8675 URL: https://issues.jboss.org/browse/WFLY-8675 Project: WildFly Issue Type: Task Components: EJB, Security Reporter: Brian Stansberry Assignee: Brian Stansberry ServiceVerificationHandler was deprecated 30 months ago. EJB and picketlink subsystems are still using it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8570) Get rid of use of ServiceVerificationHandler

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-8570?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-8570: ----------------------------------- Fix Version/s: (was: 12.0.0.Alpha1) > Get rid of use of ServiceVerificationHandler > -------------------------------------------- > > Key: WFLY-8570 > URL: https://issues.jboss.org/browse/WFLY-8570 > Project: WildFly > Issue Type: Task > Components: EJB, Security > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > ServiceVerificationHandler was deprecated 30 months ago. EJB and picketlink subsystems are still using it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8410) Test suite depends on the WFCORE-1762 bug

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-8410?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-8410: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9989 > Test suite depends on the WFCORE-1762 bug > ----------------------------------------- > > Key: WFLY-8410 > URL: https://issues.jboss.org/browse/WFLY-8410 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > A number of places in the full WildFly test suite depend on the incorrect behavior that WFCORE-1762 is meant to fix. Tests execute operations that should fail and assume they will succeed. > InterDeploymentDependenciesTestCase and InterDeploymentDependenciesEarTestCase are like this. There may be (many) others. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017