May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFCORE-13: ---------------------------------------- WFCORE-13 somewhat "blocks" WFCORE-389 because in theory a subsystem that registers a runtime-only op in the domain-wide profile resource tree may want that op executed on servers *only* via the domain, not allowing the user to invoke it on individual servers. The mechanism to do that would be to mark the op as private in the server-level management API. This is to some extent a purely theoretical situation. > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2719) Better use of the ManagementResourceRegistration data in JMX query handling

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2719?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2719: ------------------------------------- Description: For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match. Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code} No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level. (Remember, the key/value pairs in an ObjectName are not required to be in a particular order so we can't assume the order matches the order of key/value pairs in a PathAddress. So we'd have to look for any resource with an address with a PathElement at any position whose key is 'j2eetype' or 'socket-binding'.) Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify on those parts of the tree where a Resource search is necessary. was: For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match. Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code} No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level. Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary. > Better use of the ManagementResourceRegistration data in JMX query handling > --------------------------------------------------------------------------- > > Key: WFCORE-2719 > URL: https://issues.jboss.org/browse/WFCORE-2719 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, JMX > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match. > Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code} > No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level. (Remember, the key/value pairs in an ObjectName are not required to be in a particular order so we can't assume the order matches the order of key/value pairs in a PathAddress. So we'd have to look for any resource with an address with a PathElement at any position whose key is 'j2eetype' or 'socket-binding'.) > Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify on those parts of the tree where a Resource search is necessary. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2748) Move the configuration setup & tests for -Delytron from wildfly to wildfly-core

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2748?page=com.atlassian.jira.plugi... ] Ken Wills updated WFCORE-2748: ------------------------------ Summary: Move the configuration setup & tests for -Delytron from wildfly to wildfly-core (was: Move the configuration set & tests for -Delytron from wildfly to wildfly-core) > Move the configuration setup & tests for -Delytron from wildfly to wildfly-core > ------------------------------------------------------------------------------- > > Key: WFCORE-2748 > URL: https://issues.jboss.org/browse/WFCORE-2748 > Project: WildFly Core > Issue Type: Sub-task > Reporter: Ken Wills > > The current full testsuite performs alternate setup for tests when -Delytron is used prior to executing tests. This configuration should be migrated to core. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2748) Move the configuration set & tests for -Delytron from wildfly to wildfly-core

by Ken Wills (JIRA)

Ken Wills created WFCORE-2748: --------------------------------- Summary: Move the configuration set & tests for -Delytron from wildfly to wildfly-core Key: WFCORE-2748 URL: https://issues.jboss.org/browse/WFCORE-2748 Project: WildFly Core Issue Type: Sub-task Reporter: Ken Wills The current full testsuite performs alternate setup for tests when -Delytron is used prior to executing tests. This configuration should be migrated to core. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from core to full

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ] Ken Wills commented on WFCORE-2746: ----------------------------------- The domain tests & subclasses of AbstractSlaveHCAuthenticationTestCase are reasonably easy ones to move. (I'd just tested moving the elytron specific one (SlaveHostControllerElytronAuthenticationTestCase). > Move elytron management security tests from core to full > -------------------------------------------------------- > > 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 > > 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. > 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.* > org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase > org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1] > [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. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from core to full

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ] Ken Wills commented on WFCORE-2746: ----------------------------------- I saw the vault one yesterday, and added it as one to look at later. We do seem to have some other vault stuff available in core too, as you mention. Its the test that tests all of the various mechanisms for a slave to auth to a master AFAIR. > Move elytron management security tests from core to full > -------------------------------------------------------- > > 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 > > 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. > 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.* > org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase > org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1] > [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. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2747) Elytron support in WildFly Test Runner

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2747: ---------------------------------------- Summary: Elytron support in WildFly Test Runner Key: WFCORE-2747 URL: https://issues.jboss.org/browse/WFCORE-2747 Project: WildFly Core Issue Type: Sub-task Components: Domain Management, Security, Test Suite Reporter: Brian Stansberry Assignee: James Perkins Allow the management clients controlled by WildFly Test Runner to use elytron nicely. This requires general support in controller-client itself, which is generally useful, not just for this testsuite. And then the integration bits to allow users to integrate a wildfly-config.xml into the test Server. And also ???? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from core to full

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2746: ---------------------------------------- Summary: Move elytron management security tests from core to full 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 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. 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.* org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1] [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. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8683) Upgrade transaction client to 1.0.0.Beta22

by David Lloyd (JIRA)

David Lloyd created WFLY-8683: --------------------------------- Summary: Upgrade transaction client to 1.0.0.Beta22 Key: WFLY-8683 URL: https://issues.jboss.org/browse/WFLY-8683 Project: WildFly Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1121) NPE and bugs related to SASL selector parsing

by David Lloyd (JIRA)

David Lloyd created ELY-1121: -------------------------------- Summary: NPE and bugs related to SASL selector parsing Key: ELY-1121 URL: https://issues.jboss.org/browse/ELY-1121 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client, XML Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Beta41 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

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