Bug 1015524 - RBAC: unable to deploy the same deployment which was already deployed by user from different server-group scope
RBAC: unable to deploy the same deployment which was already deployed by user...
Status: NEW
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity high
: ---
: EAP 6.4.0
Assigned To: Brian Stansberry
Ladislav Thon
Russell Dickenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-04 08:49 EDT by Radim Hatlapatka
Modified: 2015-05-19 06:17 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
When role-based access controls are enabled, management users with server-group scoped roles might have new deployments fail with the following message: ---- "JBAS014807: Management resource '[(\"deployment\" => \"example.war\")]' not found" ---- This occurs because a deployment with the same name already exists in the domain. This is correct behaviour. However because the management user is scoped to a server group, they will be unable to see if such a deployment already exists in another server group. This makes it difficult to avoid this confusing error. To workaround this limitation, Red Hat recommends that either non-scoped roles are assigned to the users responsible for adding deployments to a domain, or that a list of deployment names is maintained so that management users are aware of them.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Enhancement
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker HAL-283 Major Open Support addressable but non-readable resources 2017-03-22 19:48 EDT

  None (edit)
Description Radim Hatlapatka 2013-10-04 08:49:12 EDT
Description of problem:
When trying to deploy deployment which was already uploaded to a content repository in different server-group scope, it is not possible to upload the same deployment by user with rights for different server-group scope.

It ends up with a please wait dialog (Your request is being processed ...) and error message in message box:

Deployment failed: testJira-1.0.war: {"outcome" : "failed", "failure-description" : "JBAS014807: Management resource '[(\"deployment\" => \"testJira-1.0.war\")]' not found", "rolled-back" : true}

Version-Release number of selected component (if applicable):
EAP 6.2.0.ER4

How reproducible:


Steps to Reproduce:
1. start server in domain mode with prepared users and suitable rbac mapping
2. log as deployer for other-server-group scope
3. upload a deployment to content repository
4. log as a deployer user for main-server-group scope
5. try to upload the same deployment to the content repository

Actual results:
dialog showing please wait + error message


Expected results:
uploaded deployment


Additional info:
Comment 1 Brian Stansberry 2013-10-04 12:08:31 EDT
If you give the deployment the same name, this should not work; i.e. not being able to do that is not a bug. That deployment name is owned by a different server group for which you do not have write permissions.

The same content can be registered in the domain with two different names, and the runtime-name attribute on those management resources can be used to ensure that the deployment is handled correctly (e.g. expected context path in HTTP urls) on the servers. For example, deployment=foo-server-group-a and deployment=foo-server-group-b could both use runtime-name=foo.war.

The "JBAS014807: Management resource '[(\"deployment\" => \"testJira-1.0.war\")]' not found" error message is not ideal. That's a result of a bit of general behavior that we'll have to re-evaluate between now and GA.

The general behavior is resources that a server-group-scoped-role could see if they were in scope (i.e. deployments, profiles, socket-binding-groups, server-configs, servers) are invisible to members of that s-g-s-r if they are out of scope. The management layer reacts as if they don't even exist.

The alternative to this would be to not make those resources invisible but to make them read-only, the way we do with things unrelated to the scoped role like /system-property=x or /host=y.

The upside to the current approach is the user gets a view of the domain that looks like it would if only their server group exists. There aren't a bunch of other resources that they can see but are somehow off limits.

The downside is in reality these off limits resources do exist, and their existence can have an impact on the user. For example, the problem reported here -- user tries to create a 2nd deployment=foo.war unaware that the domain already has one.

If we changed things such that the user could see deployment=foo.war but not write to it, trying to replace the deployment content would still not work (correctly so) but the user would get a more useful error message.
Comment 2 Ladislav Thon 2013-10-07 02:11:48 EDT
If the content repository is global (which IIUC it is), then I believe that everyone who can write to it should be aware of its contents (= addressable for roles that can do deployments). Individual entries in the content repository should NOT be readable for everyone, only for respective owners. I'm not sure how feasible that is.

To be perfectly honest, I'm not even sure about the addressability, even the address can reveal some information -- but given that in current state, one is able to reveal that exact information by uploading a specifically named deployment, it's probably not a big deal.
Comment 3 Brian Stansberry 2013-10-07 15:36:37 EDT
I'm not sure whether making the resources addressable but not readable is feasible; I'll check.

This would need to be consistent across all the relevant types: deployment, deployment-overlay, profile, socket-binding-group, server-config, server and IIRC host.

Note that as soon as an item was mapped to the server-group it would become readable. In the case of a deployment that is relatively easily done as the deployment can be mapped but the mapping not enabled (so the deployment wouldn't actually get deployed into the runtime.)
Comment 4 Ladislav Thon 2013-10-08 02:36:00 EDT
In case we are not able to make the resources addressable and non-readable, I'd prefer keeping the status quo. In fact, I think that the layers above the management layer could account for this situation and provide a more helpful error message -- I believe that would be a lot better than letting people read deployments from server groups that they don't have perms to.

Once the deployment is assigned to a server group, it should of course become readable by that server-group's deployers.
Comment 6 Brian Stansberry 2013-10-15 09:32:05 EDT
Making these resources readable is not OK with QE (and I don't argue with that), but making them addressable only will likely lead to worse usability problems and or major bugs in the console, with no time to correct these. So devel_ack- on this for 6.2.0.
Comment 8 JBoss JIRA Server 2013-11-05 06:06:22 EST
Heiko Braun <ike.braun@googlemail.com> made a comment on jira HAL-283

{code}
[domain@localhost:9990 /] :read-children-names(child-type=server-group){roles=main-servers}
{
    "outcome" => "success",
    "result" => ["main-server-group"],
    "response-headers" => {"access-control" => [{
        "absolute-address" => [],
        "relative-address" => [],
        "filtered-children-types" => ["server-group"]
    }]}
}

{code}
Comment 9 JBoss JIRA Server 2013-11-05 06:08:38 EST
Heiko Braun <ike.braun@googlemail.com> made a comment on jira HAL-283

How would addressable, non-readable resources be represented when doing read operations liek the one below? Would they appear with by name in the access-control header?

{code}
[domain@localhost:9990 /] :read-children-names(child-type=server-group){roles=main-servers}
{
    "outcome" => "success",
    "result" => ["main-server-group"],
    "response-headers" => {"access-control" => [{
        "absolute-address" => [],
        "relative-address" => [],
        "filtered-children-types" => ["server-group"]
    }]}
}

{code}
Comment 10 JBoss JIRA Server 2013-11-05 06:13:23 EST
Heiko Braun <ike.braun@googlemail.com> made a comment on jira HAL-283

How would addressable, non-readable resources be represented when doing read operations like the one below? 

Here's an example of non-addressable resources:

{code}
[domain@localhost:9990 /] :read-children-names(child-type=server-group){roles=main-servers}
{
    "outcome" => "success",
    "result" => ["main-server-group"],
    "response-headers" => {"access-control" => [{
        "absolute-address" => [],
        "relative-address" => [],
        "filtered-children-types" => ["server-group"]
    }]}
}

{code}

Would they addressable, non-readable appear with by name in the access-control header?
Comment 11 JBoss JIRA Server 2013-11-05 06:13:38 EST
Heiko Braun <ike.braun@googlemail.com> made a comment on jira HAL-283

How would addressable, non-readable resources be represented when doing read operations ?

Here's an example of non-addressable resources:

{code}
[domain@localhost:9990 /] :read-children-names(child-type=server-group){roles=main-servers}
{
    "outcome" => "success",
    "result" => ["main-server-group"],
    "response-headers" => {"access-control" => [{
        "absolute-address" => [],
        "relative-address" => [],
        "filtered-children-types" => ["server-group"]
    }]}
}

{code}

Would they addressable, non-readable appear with by name in the access-control header?
Comment 12 JBoss JIRA Server 2013-11-05 06:45:03 EST
Heiko Braun <ike.braun@googlemail.com> made a comment on jira HAL-283

I think we need clarification on the policy enforcement for these operations on addressable, non-readable-resources:

a) read-children-names
b) read-children-resources
c) read-resource 
d) read-reasource-description 

Do these enforcement rules sound reasonable:

a) inludes the adressable resource names
b) filter non-readable, but provide an access-control respponse header indicating that there are additional, addressables ones that have been filtered
c) for wildcards: same as b); for specific instances either error or success response
d) same as c)
Comment 13 JBoss JIRA Server 2013-11-05 06:45:13 EST
Heiko Braun <ike.braun@googlemail.com> made a comment on jira HAL-283

I think we need clarification on the policy enforcement for these operations on addressable, non-readable-resources:

a) read-children-names
b) read-children-resources
c) read-resource 
d) read-reasource-description 

Do these enforcement rules sound reasonable?

a) inludes the adressable resource names
b) filter non-readable, but provide an access-control respponse header indicating that there are additional, addressables ones that have been filtered
c) for wildcards: same as b); for specific instances either error or success response
d) same as c)
Comment 14 JBoss JIRA Server 2013-11-05 06:45:30 EST
Heiko Braun <ike.braun@googlemail.com> made a comment on jira HAL-283

I think we need clarification on the policy enforcement for these operations on addressable, non-readable-resources:

a) read-children-names
b) read-children-resources
c) read-resource 
d) read-reasource-description 

Do these enforcement rules sound reasonable?

a) inludes the adressable resource names
b) filter non-readable, but provide an access-control response header indicating that there are additional, addressables ones that have been filtered
c) for wildcards: same as b); for specific instances either error or success response
d) same as c)
Comment 15 JBoss JIRA Server 2013-11-05 12:30:44 EST
Brian Stansberry <brian.stansberry@redhat.com> made a comment on jira HAL-283

When I get some time I'll make security-domain addressable (but still not readable) and will show you the output. Won't push that change of course. :) I can't think of any resources that are that way already, so using security-domain is a simple way to experiment.

My expectation is it will conform to this from https://docs.google.com/document/d/1_Lz8ILDuWN9ZWJSUQZGnB3DIQ1sDGR5UGPCZeP3rKvE . The "read-restricted-children" subheader is in the area of your "b".

response filtering - when the user request attempts to read multiple targets, where the user has privileges to read some but not all of the targets. The response will not include values for the restricted targets, but will include a response header indicating which attributes were filtered. If the user wasn’t allowed to even be aware of the existence of certain targets, the response header will indicate the type of the resources (e.g. security-domain, security-realm) that were omitted. The intent is the management client can use the response header information to tailor an appropriate user interface. For example, if the response indicates access to an attribute was denied, a GUI could show a greyed out label and value for the attribute. 

{code}
[standalone@localhost:9999 /] /subsystem=messaging:read-resource(recursive=true)
{
   "outcome" => "success",
   "result" => 
   {
       "foo" => "1000",
       “bar”, => true,
       "cluster-user" => undefined,
       "cluster-password"  => undefined
   },
   "response-header" =>
   {
      "access-denied" => 
      {
          "attributes" => [ "cluster-user", "cluster-password" ],
          "read-restricted-children" => 
          [
             ( "some-type" => "a"),
             ( "some-type" => "b")
          ],
          "hidden-children-types" => [ "security-setting" ]
      }
   }
}
{code}
Comment 16 JBoss JIRA Server 2013-11-05 17:26:45 EST
Brian Stansberry <brian.stansberry@redhat.com> made a comment on jira HAL-283

Attached is the CLI input showing the results of various ops performed by a Monitor against resources that are either non-addressable or addressable, but not readable.

Comments on the results:

1) read-children-names
a) non-addressable -- OK
b) addressable, non-readable -- OK

2) read-children-resources
a) non-addressable -- OK
b) addressable, non-readable -- OK; note the "unreadable-children" response header

3) read-resource
a) non-addressable
i) non-wildcard -- OK
ii) wildcard -- result is ok, but no response header is provided to report on filtering
b) addressable, non-readable
i) non-wildcard -- OK
ii) wildcard -- result is so-so (may have to live with it), but no response header is provided to report on filtering

4) read-resource-description

Here the results are a bit odd. Basically when doing r-r-d for type=x, it doesn't matter what value you provide for "x", you get the generic description of that type as if you provided type=*. You could use /core-service=management/security-realm=bogusmadeupvalue and get the same response. So providing the response doesn't leak the existence of addresses. But it's odd.

Changing it would be something we'd have to think hard about as it would be a behavior change users may not expect.
Comment 17 JBoss JIRA Server 2013-11-05 17:34:23 EST
Brian Stansberry <brian.stansberry@redhat.com> made a comment on jira HAL-283

JIRA for 3)a)ii) and 3)b)ii)

https://issues.jboss.org/browse/WFLY-2444

Note You need to log in before you can comment on or make changes to this bug.