Bug 1017786 - RBAC: Deployer can't modify data source when datasources set as application resources
RBAC: Deployer can't modify data source when datasources set as application r...
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ER7
: EAP 6.2.0
Assigned To: Brian Stansberry
Ladislav Thon
Russell Dickenson
Depends On: 1019107
  Show dependency treegraph
Reported: 2013-10-10 09:51 EDT by Ladislav Thon
Modified: 2014-05-26 21:29 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
Causes: Consequence: Workaround (if any): Result:
Story Points: ---
Clone Of:
Last Closed: 2013-12-15 11:18:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
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 WFLY-2278 Major Resolved Deployer can't modify data source when datasources set as application resources 2014-06-06 14:18:28 EDT

  None (edit)
Description Ladislav Thon 2013-10-10 09:51:30 EDT
When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:

/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
{"outcome" => "success"}

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
    "outcome" => "failed",
    "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
    (\"subsystem\" => \"datasources\"),
    (\"data-source\" => \"ExampleDS\")
]' -- \"JBAS013475: Permission denied\"",
    "rolled-back" => true

/core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
{"outcome" => "success"}

/subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"

I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called "RBAC test case for application types").
Comment 2 Brian Stansberry 2013-10-12 17:44:53 EDT
The fix resolves the issue with the CLI, but I see that in the console the Deployer role still doesn't have permissions. The output of the access control metadata is correct though; the deployer role has write perms for all non-sensitive attributes and execute perms for all operations.
Comment 3 JBoss JIRA Server 2013-10-14 02:33:28 EDT
Ladislav Thon <lthon@redhat.com> made a comment on jira WFLY-2278

If the console still has a problem, do we want to file a HAL issue? Or is it enough to cc [~heiko.braun]?
Comment 4 JBoss JIRA Server 2013-10-14 02:37:36 EDT
Heiko Braun <ike.braun@googlemail.com> made a comment on jira WFLY-2278

See https://issues.jboss.org/browse/HAL-273
Comment 5 JBoss JIRA Server 2013-10-14 14:59:48 EDT
Heiko Braun <ike.braun@googlemail.com> made a comment on jira WFLY-2278

I don't see these issues in the console master. I would say it's safe to say it works.
Comment 6 Dimitris Andreadis 2013-10-15 08:52:15 EDT
Yes, but does this mean we need yet another console upgrade?
Comment 8 Brian Stansberry 2013-10-15 10:27:22 EDT
I'm targeting this for ER7. I didn't set it for ER6 because although the server-side change was in, I wasn't seeing the behavior I expected in the console. But it looks like it the console that will be integrated this week doesn't have these problems.
Comment 9 Ladislav Thon 2013-11-06 07:02:02 EST
Verified with EAP 6.2.0.ER7.
Comment 10 Ladislav Thon 2013-11-06 10:05:48 EST
Moving back to ON_QA as I didn't verify it in the web console. Preliminary check indicates that this ISN'T fixed in the console, but I might have done something wrong, so I'd like Jakub to recheck.
Comment 11 Harald Pehl 2013-11-06 16:15:01 EST
The console uses @AccessControl annotations to bind 1-n resources to presenters. Presenters are the "P" in the MVP architecture used in the console. Most presenters are addressable using an URL like http://localhost:9990/console/App.html#datasources. 

When the presenter is shown for the first time, the console reads the access control metadata of its configured resources to decide whether operations can be executed or attributes are readable/writable. 

The datasource presenter is configured using the following resources:
@AccessControl(resources = {

The current implementation uses an "all-or-nothing" rule: If not all resources are writable, none will be writable. To cut a long story short. Making also the xa-data-source an application resource will give the deployer the permissions to edit both the data-source and the xa-data-source resource:

/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)

/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=xa-data-source:write-attribute(name=configured-application, value=true)
Comment 12 Brian Stansberry 2013-11-06 17:01:34 EST
This works for datasources, which is good news, but unfortunately it does not work for the other big use case for this feature, JMS queues and topics. That is, these 2 commands are insufficient to make Queues/Topics editable:


My guess as to the cause of this is that the relevant "Presenter" covers all sorts of other stuff, i.e. Connection Factories, Security Settings, Address Settings, Diverts, and these (correctly) cannot be configured to become "application resources."
Comment 15 Ladislav Thon 2013-11-07 02:18:04 EST
I can confirm that the workaround with xa-data-source works. I filed bug 1027586 for tracking and I'm moving this to verified again. The main issue is indeed solved.

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