[jboss-jira] [JBoss JIRA] (WFLY-2318) Access control exceptions missing for scoped roles

[Harald Pehl (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929795#comment-12929795 ] 

Harald Pehl commented on WFLY-2318:
-----------------------------------

I'm wondering what kind of exceptions I can expect for nested nodes? Suppose that I have setup the following groups: 

{code:xml}
<server-groups>
    <server-group name="main-server-group" profile="full">
        <jvm name="default">
            <heap size="64m" max-size="512m"/>
        </jvm>
        <socket-binding-group ref="full-sockets"/>
    </server-group>
    <server-group name="other-server-group" profile="full-ha">
        <jvm name="default">
            <heap size="64m" max-size="512m"/>
        </jvm>
        <socket-binding-group ref="full-ha-sockets"/>
    </server-group>
</server-groups>
{code}

If I ask for the rights of the JVM node using

{code}
/server-group=*/jvm=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{code}

I do get exceptions as long as there's a JVM node for the main group. If there's no JVM configurtation for "main-server-group" I don't see exceptions. Is this on purpose or am I missing something?

What I would like to see are exceptions no matter whether there's a JVM node defined or not. By that I can check if the user is allowed to *add* a JVM configuration for a specific server group. Right now I don't know how to resolve this.
                
> Access control exceptions missing for scoped roles
> --------------------------------------------------
>
>                 Key: WFLY-2318
>                 URL: https://issues.jboss.org/browse/WFLY-2318
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>
> The following setup: user with two scoped roles assigned. maintainer for "main-servers", monitor for "other-servers". Requesting the access control meta data for the server group wildcard ]does not include "exceptions". 
> Expected result: the access control meta data response contains an "exception" for each server group (main-server-group & other-server-group)
> {code}
> [domain at localhost:9999 /] ./server-group=*:read-resource-description(access-control=trim-descriptions, operations=true){roles=main-servers, other-servers}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         }
>                     },
>                     "operations" => {
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "remove" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "read-children-types" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "write-attribute" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira