You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@atlas.apache.org by "chaitali borole (Jira)" <ji...@apache.org> on 2026/09/24 07:08:00 UTC
[jira] [Updated] (ATLAS-5414) Enforce authorization on AdminResource active search list and cancel endpoints
[ https://issues.apache.org/jira/browse/ATLAS-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
chaitali borole updated ATLAS-5414:
-----------------------------------
Fix Version/s: 3.0.0
2.6.0
> Enforce authorization on AdminResource active search list and cancel endpoints
> ------------------------------------------------------------------------------
>
> Key: ATLAS-5414
> URL: https://issues.apache.org/jira/browse/ATLAS-5414
> Project: Atlas
> Issue Type: Improvement
> Components: atlas-webui
> Affects Versions: 3.0.0
> Reporter: chaitali borole
> Assignee: chaitali borole
> Priority: Major
> Fix For: 3.0.0, 2.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Summary
> The GET and DELETE handlers for /api/atlas/admin/activeSearches in AdminResource do not use the same authorization pattern as other admin endpoints in that class.
> Background
> When a metadata search runs for a long time, Atlas registers it in SearchTracker so administrators can observe and cancel active queries. Those operations are exposed under the admin REST API and are intended to be restricted to privileged users, consistent with endpoints such as debug metrics, export, and audits.
> A prior change added authorization to many AdminResource handlers but did not include the active search list and cancel endpoints.
> Current behavior
> GET /api/atlas/admin/activeSearches returns the set of active search IDs with no privilege check.
> DELETE /api/atlas/admin/activeSearches/{id} cancels a search by ID with no privilege check.
> SearchTracker keys entries by the executing thread name and does not record which user initiated the search, so cancellation cannot be limited to the initiating user or an administrator.
> Expected behavior
> Listing all active searches requires an administrative privilege (aligned with other operational admin APIs, e.g. ADMIN_EXPORT).
> Cancelling a search is allowed for users with that administrative privilege, or for the user who started the search; other users should receive the standard Atlas authorization failure response.
> Each tracked search should record the initiating user at registration time for ownership checks on cancel.
> Proposed changes
> AdminResource
> Call AtlasAuthorizationUtils.verifyAccess with ADMIN_EXPORT before returning active search IDs.
> On terminate: allow if the caller has ADMIN_EXPORT; otherwise allow only when the search owner matches the current user; otherwise enforce authorization (403).
> SearchTracker
> Store the initiating user (from RequestContext.getCurrentUser()) when a search is added.
> Expose owner lookup by search ID for the REST layer.
> Tests
> Update AdminResourceTest for the new authorization paths.
> Add SearchTrackerTest for owner recording and terminate behavior.
> Test plan
> Unprivileged user: GET /api/atlas/admin/activeSearches → 403 (same as other admin endpoints such as debug metrics).
> User A runs searches; user B (without admin export) → cannot list all active searches; cannot cancel A’s search (403).
> User A can cancel their own in-flight search when not granted admin export (if product accepts owner-only cancel).
> User with ADMIN_EXPORT can list and cancel any active search.
> Existing unit tests for AdminResource and new SearchTracker tests pass.
> Affected components
> atlas-webapp: org.apache.atlas.web.resources.AdminResource
> atlas-repository: org.apache.atlas.util.SearchTracker
--
This message was sent by Atlassian Jira
(v8.20.10#820010)