Bug 1019784

Ladislav Thon <lthon> made a comment on jira WFLY-2317

I believe that this commit might be the cause: https://github.com/wildfly/wildfly/commit/6e35f084deeeb1df3c555bcdda121b7cd157cea2 At least it is the reason why I wrote that test case.

I don't believe this should be "high" severity. See https://bugzilla.redhat.com/show_bug.cgi?id=1015524#c1 for an explanation of why the other server groups are not addressable. It's really not an attempt to hide sensitive data. It's an unsuccessful attempt to provide a coherent view of the resource tree to the user. Ideally these resources would be addressable but not readable, but we can't do that for 6.2 without introducing too much risk for breaking things in the console.

No argument that if the resource is not supposed to be addressable a permission denied response is not correct.

If this is not supposed to hide sensitive data (which I believed is the case), then I'm lowering the severity to medium. Still, :read-resource and :remove on a non-addressable resource should give the same answer.

One more thing -- if we have these resources non-addressable now and we'll try to make them addressable & non-readable in the future, that might be considered a regression by some customers. I'm not sure what my feelings about that would be.

This is reproducible on ER6 using the same instructions as in the upstream issue. Copying those instructions here for reference.

On a freshly unpacked EAP 6.2.0.ER6 with added "admin" user into domain/configuration/mgmt-users.properties, the problem can be reproduced like this:

[1] ./bin/domain.sh
[2] ./bin/jboss-cli.sh -c
    /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
    /core-service=management/access=authorization/role-mapping=NewRole:add
    /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
    /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    exit
[1] ^C
    ./bin/domain.sh
[2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
    /server-group=other-server-group:read-resource
    /server-group=other-server-group:remove

What does that mean? The "NewRole" role is scoped to the "main-server-group" server group and can't see the "other-server-group" group. When doing "/server-group=other-server-group:read-resource", this is correctly enforced and the output looks like this:

{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
    "rolled-back" => true
}

However, trying to do "/server-group=other-server-group:remove", which is only a different operation _on the same resource_, I get a different error message:

{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
    "rolled-back" => true
}

I expect the error message to be completely the same as in previous case, not leaking any information that the "other-server-group" group actually exists.

Ladislav Thon <lthon> made a comment on jira WFLY-2317

I've rebased the branch and submitted a pull request (the branch/PR contains some more tests than this one). In the PR, I changed the test to pass and added a comment to explain that it shouldn't be Outcome.UNAUTHORIZED but Outcome.HIDDEN.

Brian Stansberry <brian.stansberry> updated the status of jira WFLY-2317 to Coding In Progress

Verified with EAP 6.2.0.ER7.