jcabrerizo opened a new pull request, #1436: URL: https://github.com/apache/brooklyn-server/pull/1436
`ActivityResource.cancel()` only checked `SEE_ENTITY` (via the shared `findTask()` helper used by every read endpoint in the class) before calling `Task.cancel()`. Any user entitled to merely view an entity's activity - including the built-in readonly role - could cancel another user's in-flight task or effector invocation on it, with no check for a write-capable entitlement. `children()` and `getAllChildrenAsMap()` had a related, narrower gap: they checked `SEE_ENTITY` once against the root task, then serialized every descendant task in the tree unfiltered. Under a fine-grained EntitlementManager that restricts `SEE_ENTITY` per entity, this could expose task result/status/entity details for entities the caller isn't entitled to see, as long as they could see some ancestor task. Add `checkCancelEntitled()` (`MODIFY_ENTITY`) before `cancel()` mutates the task, and `canSeeEntity()` to filter descendant tasks by `SEE_ENTITY` in both listing endpoints, following the same per-item filtering convention already used elsewhere (e.g. `ApplicationResource`). A filtered-out task is excluded from its own listing but traversal still descends into its subtree, so visible descendants further down are still reported. Add `ActivityResourceEntitlementsTest` covering: cancel permissions across root/user/readonly/minimal roles and a fine-grained per-entity custom EntitlementManager, and children()/recurse filtering across a multi-entity task tree (parent/child/grandchild tagged to different entities). Assisted-by: Claude -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
