[jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions missing for non-existent resources
Brian Stansberry (JIRA)
issues at jboss.org
Tue Sep 29 10:52:00 EDT 2015
[ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113365#comment-13113365 ]
Brian Stansberry edited comment on WFCORE-832 at 9/29/15 10:51 AM:
-------------------------------------------------------------------
Edited to replace char '*' with 'x' to avoid JIRA formatting issues.
The basic format looks like what I expect if there's something about the server group that is different: there's an exception entry for server-group=main-server-group/deployment=x.
Are the contents of that exception entry correct given the roles involved? I'm just asking; I have no idea.
I'm curious what it looks like if main-server-group actually has a couple deployments. Intuitively I would expect two or 3 exception entries:
1) server-group=main-server-group/deployment=one
2) server-group=main-server-group/deployment=two
3) PERHAPS: server-group=main-server-group/deployment=x
I might be wrong though; I'm a bit unclear about what drives the "exceptions". Is there one for every actual *resource* that has different perms? Or is it for some sort of "address pattern" kind of thing? The server-group=main-server-group/deployment=x address isn't an actual resource address, nor is it the address under which a resource definition is registered (that's server-group=x/deployment=x). It's kind of a mix of an actual resource address element (server-group=m-s-g) and the address under which a child def is registered (deployment=x).
It seems the exception has to be some sort of "address pattern" thing; otherwise there is no sensible result for the request you posted.
In that case, it seems logical that if there actually were deployment=one and deployment=two present, the result would still be the single exception entry you posted, for server-group=main-server-group/deployment=x. There is no need entries for server-group=main-server-group/deployment=one|two, as those are just concrete instances of the server-group=main-server-group/deployment=x address pattern.
was (Author: brian.stansberry):
The basic format looks like what I expect if there's something about the server group that is different: there's an exception entry for server-group=main-server-group/deployment=*.
Are the contents of that exception entry correct given the roles involved? I'm just asking; I have no idea.
I'm curious what it looks like if main-server-group actually has a couple deployments. Intuitively I would expect two or 3 exception entries:
1) server-group=main-server-group/deployment=one
2) server-group=main-server-group/deployment=two
3) PERHAPS: server-group=main-server-group/deployment=*
I might be wrong though; I'm a bit unclear about what drives the "exceptions". Is there one for every actual *resource* that has different perms? Or is it for some sort of "address pattern" kind of thing? The server-group=main-server-group/deployment=* address isn't an actual resource address, nor is it the address under which a resource definition is registered (that's server-group=*/deployment=*). It's kind of a mix of an actual resource address element (server-group=m-s-g) and the address under which a child def is registered (deployment=*).
It seems the exception has to be some sort of "address pattern" thing; otherwise there is no sensible result for the request you posted.
In that case, it seems logical that if there actually were deployment=one and deployment=two present, the result would still be the single exception entry you posted, for server-group=main-server-group/deployment=*. There is no need entries for server-group=main-server-group/deployment=one|two, as those are just concrete instances of the server-group=main-server-group/deployment=* address pattern.
> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
> Key: WFCORE-832
> URL: https://issues.jboss.org/browse/WFCORE-832
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Harald Pehl
> Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block:
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("server-group" => "*")],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "attributes" => undefined,
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {
> "deployment" => {"model-description" => undefined},
> "jvm" => {"model-description" => undefined},
> "deployment-overlay" => {"model-description" => undefined},
> "system-property" => {"model-description" => undefined}
> },
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => false,
> "attributes" => {
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "profile" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-default-interface" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => false
> }
> },
> "operations" => {
> "read-children-types" => {"execute" => true},
> "whoami" => {"execute" => true},
> "map-clear" => {"execute" => false},
> "list-get" => {"execute" => true},
> "write-attribute" => {"execute" => false},
> "replace-deployment" => {"execute" => false},
> "stop-servers" => {"execute" => false},
> "remove" => {"execute" => false},
> "list-add" => {"execute" => false},
> "map-put" => {"execute" => false},
> "read-attribute-group-names" => {"execute" => true},
> "restart-servers" => {"execute" => false},
> "resume-servers" => {"execute" => false},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => false},
> "suspend-servers" => {"execute" => false},
> "reload-servers" => {"execute" => false},
> "query" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "map-get" => {"execute" => true},
> "list-clear" => {"execute" => false},
> "read-attribute" => {"execute" => true},
> "map-remove" => {"execute" => false},
> "read-attribute-group" => {"execute" => true},
> "undefine-attribute" => {"execute" => false},
> "read-children-names" => {"execute" => true},
> "start-servers" => {"execute" => false},
> "read-operation-names" => {"execute" => true},
> "list-remove" => {"execute" => false},
> "read-children-resources" => {"execute" => true}
> }
> },
> "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
> "read" => true,
> "write" => true,
> "attributes" => {
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "profile" => {
> "read" => true,
> "write" => true
> },
> "socket-binding-default-interface" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => true
> },
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => false
> }
> },
> "operations" => {
> "read-children-types" => {"execute" => true},
> "whoami" => {"execute" => true},
> "map-clear" => {"execute" => true},
> "list-get" => {"execute" => true},
> "write-attribute" => {"execute" => true},
> "replace-deployment" => {"execute" => true},
> "stop-servers" => {"execute" => true},
> "remove" => {"execute" => false},
> "list-add" => {"execute" => true},
> "map-put" => {"execute" => true},
> "read-attribute-group-names" => {"execute" => true},
> "restart-servers" => {"execute" => true},
> "resume-servers" => {"execute" => true},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => false},
> "suspend-servers" => {"execute" => true},
> "reload-servers" => {"execute" => true},
> "query" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "map-get" => {"execute" => true},
> "list-clear" => {"execute" => true},
> "read-attribute" => {"execute" => true},
> "map-remove" => {"execute" => true},
> "read-attribute-group" => {"execute" => true},
> "undefine-attribute" => {"execute" => true},
> "read-children-names" => {"execute" => true},
> "start-servers" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "list-remove" => {"execute" => true},
> "read-children-resources" => {"execute" => true}
> },
> "address" => [("server-group" => "main-server-group")]
> }}
> }
> }
> }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("server-group" => "*"),
> ("deployment" => "*")
> ],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
> "attributes" => undefined,
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {},
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => false,
> "attributes" => {
> "enabled" => {
> "read" => true,
> "write" => false
> },
> "name" => {
> "read" => true,
> "write" => false
> },
> "runtime-name" => {
> "read" => true,
> "write" => false
> }
> },
> "operations" => {
> "read-children-types" => {"execute" => true},
> "whoami" => {"execute" => true},
> "map-clear" => {"execute" => false},
> "list-get" => {"execute" => true},
> "write-attribute" => {"execute" => false},
> "remove" => {"execute" => false},
> "deploy" => {"execute" => false},
> "list-add" => {"execute" => false},
> "map-put" => {"execute" => false},
> "read-attribute-group-names" => {"execute" => true},
> "redeploy" => {"execute" => false},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => false},
> "query" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "map-get" => {"execute" => true},
> "list-clear" => {"execute" => false},
> "read-attribute" => {"execute" => true},
> "map-remove" => {"execute" => false},
> "read-attribute-group" => {"execute" => true},
> "undefine-attribute" => {"execute" => false},
> "read-children-names" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "list-remove" => {"execute" => false},
> "read-children-resources" => {"execute" => true},
> "undeploy" => {"execute" => false}
> }
> },
> "exceptions" => {}
> }
> }
> }]
> }
> {code}
> Some notes on the domain:
> - Built from WildFly 10 master
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the jboss-jira
mailing list