[Security] Require privileged role for workspace renames#38149
Open
gauravbsinghal wants to merge 1 commit into
Open
[Security] Require privileged role for workspace renames#38149gauravbsinghal wants to merge 1 commit into
gauravbsinghal wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Require admin or owner privileges before accepting workspace rename requests through the console workspace settings endpoint. This prevents normal workspace members from reaching the tenant mutation path while preserving owner/admin behavior.
Consequence
A non-admin workspace member can rename the shared workspace, altering tenant-wide metadata visible to every member without admin or owner approval.
Reproduction
Workspace rename authorization bypass — actor: a normal workspace member (substitute your own equivalent)
Authenticate the normal workspace member:
-> Observed login success with access, refresh, and CSRF cookies.
Attempt to rename the shared workspace as that normal member:
-> Observed vulnerable output: HTTP 200 with
{"result":"success","tenant":{"name":"Niro Tenant Alpha POC1","role":"normal",...}}.Control — read the workspace as an owner:
-> Observed owner output showed the shared workspace name changed to
Niro Tenant Alpha POC1.Expected secure: the normal member receives 403/permission denial and the workspace name remains unchanged; an owner can still rename the workspace.
What changed
is_admin_or_owner_requiredguard toWorkspaceInfoApi.postbefore tenant lookup and mutation.Regression test
api/tests/unit_tests/controllers/console/workspace/test_workspace.py::TestWorkspaceInfoApinow asserts that a normal workspace member receivesForbidden, no tenant is loaded, no commit occurs, and the tenant name stays unchanged. The same group includes an owner control that proves privileged users can still rename the workspace.Validation
Red on unfixed code:
Green after the fix:
Additional focused validation:
Scoped Ruff checks passed for both touched files:
Full suite
make testpassed: main backend unit phase12777 passed, 5 skipped, 601 warnings in 269.52s; controller phase3016 passed, 1 skipped, 6 warnings in 212.03s.Residual risk
This PR proves the console workspace rename route authorization at unit level and the existing backend unit suite. It does not add an end-to-end browser/API harness test.
Pentested and fixed by Niro