Bug 1092206 - OperationContextImpl.readResourceForUpdate assumes all resources represent persistent config
Summary: OperationContextImpl.readResourceForUpdate assumes all resources represent pe...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER4
: EAP 6.3.0
Assignee: Brian Stansberry
QA Contact: Petr Kremensky
Nichola Moore
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-29 01:24 UTC by Brian Stansberry
Modified: 2014-08-12 02:08 UTC (History)
4 users (show)

(edit)
In this previous releases of JBoss EAP 6, the operation execution logic assumed all management resources represented persistent configuration when handling the `readResourceForUpdate` method for an `OperationStepHandler`.

As a result, the `subsystem=transaction/log-store=log-store` resource's 'probe' operation and the `subsystem=transaction/log-store=log-store/transactions=*` resource's 'delete' operation could not be invoked by an admin in the 'Operator' role. 

This issue has been corrected in this release.
Clone Of:
(edit)
Last Closed: 2014-06-28 15:30:33 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-3017 Major Resolved OperationContextImpl.readResourceForUpdate assumes all resources represent persistent config 2017-02-07 12:13 UTC

Description Brian Stansberry 2014-04-29 01:24:57 UTC
The readResourceForUpdate impl makes a few assumptions regarding the fact that a given Resource represents persistent config (i.e. Resource.isRuntime() == true):

1) It calls rejectUserDomainServerUpdates() which means an OSH running on a server could not call this.

2) It calls authorize(false, READ_WRITE_CONFIG) which means an OSH for an op available to the RBAC Operator role could not call this.

Places this impacts include LogStoreProbeHandler and LogStoreTransactionDeleteHandler which should be calling readResourceForUpdate but aren't – and can't because of this bug.

Comment 2 Scott Mumford 2014-05-14 02:03:16 UTC
Refactored release note text for this as a Known Issue (ER4 fixes will not be picked up in the 6.3.0 Beta release)

Original note included here for use at 6.3.0 GA:

The operation execution logic assumes all management resources represent persistent configuration when handling the `readResourceForUpdate` method for an `OperationStepHandler`.

As a result, the `subsystem=transaction/log-store=log-store` resource's 'probe' operation and the `subsystem=transaction/log-store=log-store/transactions=*` resource's 'delete' operation cannot be invoked by an admin in the 'Operator' role. 

To fix this, the operation execution logic now checks the Resource or, if necessary, its `ManagementResourceRegistration` to see if it is a runtime-only resource.

The operations can be invoked by a user in the Operator role.

Comment 3 Ladislav Thon 2014-05-23 12:31:19 UTC
OK, the code is clearly there in 6.3.0.ER4 so I'm marking this as verified.

But invoking /subsystem=transactions/log-store=log-store:probe on 6.3.0.ER3 by a user in the Operator role (RBAC enabled etc.) is by all means possible and results in {"outcome" => "success"} (on a fresh new install in the standalone-full profile), so the doc text is worth a revision.


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