[JBoss JIRA] (WFCORE-2235) Intermittent module loading failure in InterdependentDeploymentTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2235:
-------------------------------------
Fix Version/s: 4.0.0.CR1
(was: 4.0.0.Beta2)
> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
> Key: WFCORE-2235
> URL: https://issues.jboss.org/browse/WFCORE-2235
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 4.0.0.Alpha6
> Reporter: Brian Stansberry
> Assignee: Richard Opalka
> Fix For: 4.0.0.CR1
>
> Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore...
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
> 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)
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
> at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
> at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
> ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1649:
-------------------------------------
Fix Version/s: 4.0.0.CR1
(was: 4.0.0.Beta2)
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
> Fix For: 4.0.0.CR1
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-1533) Integrate Management Access Control permission assignment with Elytron
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1533:
-------------------------------------
Fix Version/s: 4.0.0.CR1
(was: 4.0.0.Beta2)
> Integrate Management Access Control permission assignment with Elytron
> ----------------------------------------------------------------------
>
> Key: WFCORE-1533
> URL: https://issues.jboss.org/browse/WFCORE-1533
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 4.0.0.CR1
>
>
> A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role.
> Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection.
> This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron.
> After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based.
> _Note: As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3181) Review CustomCredentialSecurityFactoryTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3181?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3181:
-------------------------------------
Fix Version/s: 4.0.0.CR1
(was: 4.0.0.Beta2)
> Review CustomCredentialSecurityFactoryTestCase
> ----------------------------------------------
>
> Key: WFCORE-3181
> URL: https://issues.jboss.org/browse/WFCORE-3181
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Test Suite
> Reporter: Darran Lofthouse
> Fix For: 4.0.0.CR1
>
>
> The test case CustomCredentialSecurityFactoryTestCase appears to be testing that the 'code does what it does' rather than testing the 'code is doing what it should'.
> The test is testing a custom credential security factory can be called but the test is using HTTP Basic authentication and relying on SPNEGO authentication being triggered as this is the only mechanism that currently uses this factory.
> Should a minor change be required to the SPNEGO authentication mechanism which affects when this credential factory is called this test case could subsequently fail.
> If possible it would be better to convert this test to be a SPNEGO test and then test the behaviour of the credential security factory affects the mechanism as expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3107) Allow slave hosts to ignore missing RBAC config resources
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3107?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3107:
-------------------------------------
Fix Version/s: 4.0.0.CR1
(was: 4.0.0.Beta2)
> Allow slave hosts to ignore missing RBAC config resources
> ---------------------------------------------------------
>
> Key: WFCORE-3107
> URL: https://issues.jboss.org/browse/WFCORE-3107
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 4.0.0.CR1
>
>
> Part of parent issue whereby slaves can ignore missing RBAC constraint resources for write requests coming from the DC.
> If the DC sent the request, then the address is ok overall. So if it's missing on the slave that means the slave doesn't have that constraint registered and doesn't need to handle the op.
> This fix could possibly be backported to the 2.1.x and to EAP 6.4.x in lieu of adding transformers as part of the parent issue. In the case of 2.1.x it also allows slaves to ignore the related extension even if the code for it is present (which is only a minor benefit.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2746:
-------------------------------------
Fix Version/s: 4.0.0.CR1
(was: 4.0.0.Beta2)
> Move elytron management security tests from full to core
> --------------------------------------------------------
>
> Key: WFCORE-2746
> URL: https://issues.jboss.org/browse/WFCORE-2746
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security, Test Suite
> Reporter: Brian Stansberry
> Fix For: 4.0.0.CR1
>
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> -org.jboss.as.test.integration.security.perimeter.* [2]-
> -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> -org.jboss.as.test.integration.security.credentialreference [2]-
> integration/elytron/
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months