[JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1960:
-------------------------------------
Fix Version/s: 4.0.0.Alpha6
(was: 4.0.0.Alpha5)
> Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING
> --------------------------------------------------------------------
>
> Key: WFCORE-1960
> URL: https://issues.jboss.org/browse/WFCORE-1960
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 4.0.0.Alpha6
>
> Attachments: rrd.txt
>
>
> A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute.
> I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+...) so removing the only usage of it will help.
> We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 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.Alpha6
(was: 4.0.0.Alpha5)
> 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.Alpha6
>
>
> 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)
8 years, 4 months
[JBoss JIRA] (WFCORE-1307) jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1307?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1307:
-------------------------------------
Fix Version/s: 4.0.0.Alpha6
(was: 4.0.0.Alpha5)
> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1307
> URL: https://issues.jboss.org/browse/WFCORE-1307
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Assignee: Ken Wills
> Fix For: 4.0.0.Alpha6
>
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed.
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone@localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at java.nio.file.Files.copy(Files.java:3004)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 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.5.0#75005)
8 years, 4 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.Alpha6
(was: 4.0.0.Alpha5)
> 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.Alpha6
>
>
> 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)
8 years, 4 months
[JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2497:
-------------------------------------
Fix Version/s: 4.0.0.Alpha6
(was: 4.0.0.Alpha5)
> Convert *-authentication-factory resources to be child resources of security-domain
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2497
> URL: https://issues.jboss.org/browse/WFCORE-2497
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Fix For: 4.0.0.Alpha6
>
>
> This is a good example of where child resources work.
> The authentication factory resources have a mandatory dependency on a single security domain.
> The configuration within the factory is related to it's security domain.
> There is only a single resource that can provide security domains.
> The behaviour of the parent is unaffected by the existence or configuration of the child.
> The parent and child manage their own services independently with the child's service depending on the parent's service.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months