Bug 1017786 - RBAC: Deployer can't modify data source when datasources set as application resources
Summary: RBAC: Deployer can't modify data source when datasources set as application r...
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ER7
: EAP 6.2.0
Assignee: Brian Stansberry
QA Contact: Ladislav Thon
Russell Dickenson
Depends On: 1019107
TreeView+ depends on / blocked
Reported: 2013-10-10 13:51 UTC by Ladislav Thon
Modified: 2014-05-27 01:29 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Causes: Consequence: Workaround (if any): Result:
Clone Of:
Last Closed: 2013-12-15 16:18:26 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-2278 0 Major Resolved Deployer can't modify data source when datasources set as application resources 2014-06-06 18:18:28 UTC

Description Ladislav Thon 2013-10-10 13:51:30 UTC
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 21:44:53 UTC
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 06:33:28 UTC
Ladislav Thon <lthon> 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 06:37:36 UTC
Heiko Braun <ike.braun> made a comment on jira WFLY-2278

See https://issues.jboss.org/browse/HAL-273

Comment 5 JBoss JIRA Server 2013-10-14 18:59:48 UTC
Heiko Braun <ike.braun> 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 12:52:15 UTC
Yes, but does this mean we need yet another console upgrade?

Comment 8 Brian Stansberry 2013-10-15 14:27:22 UTC
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 12:02:02 UTC
Verified with EAP 6.2.0.ER7.

Comment 10 Ladislav Thon 2013-11-06 15:05:48 UTC
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 21:15:01 UTC
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 22:01:34 UTC
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 07:18:04 UTC
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.