Jakub, could you test this with the CLI, given your setup, user "other-admin"?

/host=slave:read-children-resources(child-type=server-config,include-runtime=true)

Thanks.

Brian: Yop, seems to be a model issue

[domain@localhost:9999 /] /host=slave:read-children-resources(child-type=server-config,include-runtime=true)
Failed to get the list of the operation properties: "JBAS014807: Management resource '[("host" => "slave")]' not found"

Here's a bit of status report / brain dump on this.

This is a server-side regression in 6.4; the same behavior is there in 6.2.x. More likely the way the console works has changed a bit and an existing problem is now exposed.

The design of how server-group-scoped-roles can deal with host level resources (host=*, host=*/interface=*, etc) was meant to be like the way they relate to profiles, socket-binding-groups, deployments and other "things" that map one way or another to a server-group. If the "thing" maps to a server-group that is associated with the role, or is completely unmapped, then the s-g-s-r gets permissions, otherwise not and the thing is invisible. In this case, the "thing" maps to the server-group by having a server-config child that's in the group.

See https://issues.jboss.org/browse/WFLY-2026 and more fully, http://post-office.corp.redhat.com/archives/wildfly-rbac/2013-September/msg00024.html

The behavior we see is consistent with this. You'd see the same thing dealing with profiles. Profiles that are mapped to other server groups are invisible.

There are two problems with this behavior though:

1) /:read-children-names(child-type=host){roles=other-admin} includes "slave" in the response, but then trying to read /host=slave fails. This is inconsistent and is clearly a bug. I suspect this is why the console is failing -- it makes that call and then iterates over the result.

2) The "host" resource is different from "profile" etc in that it is a parent to a server-config resource the s-g-s-r might need to create -- a server config. So it's odd to not be able to read it. Note that other-admin actually can create a server-config on host=slave even though they can't read the parent resource:

[domain@localhost:9999 /] /host=slave/server-config=xxx:add(group=other-server-group,socket-binding-port-offset=500){roles=other-admin}
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

And once they do that, they can read host=slave just fine, since now it maps to the group.

Three possible solutions:

A) Fix the bug that allows /:read-children-names(child-type=host){roles=other-admin} to include "slave" in the response. That should hide the host from the console altogether. May break other console workflows that worked before though. For example, adding a server-config on the host. It's also likely a hard one to fix.

B) Figure out what changed in the console that led it to trip over this and correct that. Basically work around the problem. I suspect this is not trivial for the console guys.

C) Make the host=xxx resources readable by any s-g-s-r the same way they can read things that are not mappable at all, e.g. /interface=public, /system-property=foo, etc.

I'm looking into C) as it seems best. But I'm not sure at this point how hard it is to do without lots of repercussions. Note that doing this would increase the permissions of these roles in an EAP minor. I think that's ok, but it needs to be pointed out.

"This is a server-side regression in 6.4"

I meant this is NOT a server-side regression in 6.4.

Problem 1) in comment 7 is indeed what causes the problem. 

Reverting the UI change the exposed the bug (solution B) is not an option. Solution A would actually prevent creation of new servers so it's not acceptable, like Brian said. I cannot think of any side effects at the moments, therefore I agree that C) should be used to move forward.

Can confirm that the console works as expected with Brian's fix in place. The console itself does not need any further modifications, thus removing dependency to 1181430.

Heiko Braun <ike.braun> updated the status of jira HAL-558 to Resolved

verified on EAP 6.4.0.ER2