The GitHub Actions job "Required Checks" on texera.git/main has succeeded. Run started by GitHub user github-merge-queue[bot] (triggered by github-merge-queue[bot]).
Head commit for run: 289189741dad32c7d613108ecd9fe75a8eca420d / Xinyuan Lin <[email protected]> fix(amber): guard cloneWorkflow with a read-access check (#7605) ### What changes were proposed in this PR? `cloneWorkflow` fetched the source workflow by `wid` and copied its content into a workflow owned by the caller, with no access check on the way in. Any authenticated REGULAR user could `POST /workflow/clone/<wid>` for a wid they hold no privilege on and receive a full copy of a private workflow's content — operator configurations, file paths and all. **Root cause.** Every sibling on this path guards; this one endpoint did not. | Endpoint | Guard | |---|---| | `retrieveWorkflow` | `hasReadAccess` directly | | `duplicateWorkflow` | `hasReadAccess` directly | | `cloneVersion` (`/version/clone/{vid}`) | inherits it via `retrieveWorkflowVersion` | | **`cloneWorkflow`** | **none** | That reads as an oversight rather than a decision. SECURITY.md states that REGULAR users "cannot access other users' private resources without granted permissions", so the endpoint contradicted the project's own declared model. **Before → after** ``` caller with no privilege on wid | v v POST /workflow/clone/{wid} POST /workflow/clone/{wid} | | | (no check) +-- hasReadAccess(wid, uid)? --> no --> 403 v | fetchOneByWid(wid) v yes (owner / READ grant / public) | fetchOneByWid(wid) v | full content copied to caller v full content copied to caller ``` The fix adds the same three lines the siblings use. `hasReadAccess` already returns true for public workflows, so the hub's clone button — the only caller, and always acting on a published workflow — is unaffected. A caller holding an explicit READ grant can still clone. ### Any related issues, documentation, discussions? Found while reviewing the clone-endpoint test in #7592, now merged; the new cases here build on the spec helpers that landed with it. Not filed as an issue, because SECURITY.md asks that security bugs not be reported through public issues. The `release/v1.2` backport preflight comes back grey: the guard itself applies, but the two new test cases depend on helpers that arrived with #7592, which was not backported. The backport needs those cases rewritten self-contained, so it will have to be resolved by hand rather than pushed straight through. ### How was this PR tested? Two cases added to the existing `WorkflowResourceSpec`, and the pre-existing success case in #7592 now publishes its source first so it exercises the public path. | Test | Pins | |---|---| | `clone a private workflow the caller has been granted read access to` | the guard does not over-block a legitimate READ grant | | `reject a caller with no access to the source workflow` | 403, no copy reaches the caller, and no `WORKFLOW_USER_CLONES` row is written for the rejected attempt | Red before the guard, green after — with the guard reverted the rejection case fails and the other 69 pass, so it is the guard the test is pinning and not a fixture. ``` sbt "WorkflowExecutionService/testOnly org.apache.texera.web.resource.dashboard.file.WorkflowResourceSpec" ``` ``` [info] Total number of tests run: 70 [info] Tests: succeeded 70, failed 0, canceled 0, ignored 0, pending 0 ``` `scalafmtCheck` and `scalafix --check` pass for both `Compile` and `Test`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 5) Report URL: https://github.com/apache/texera/actions/runs/31670573475 With regards, GitHub Actions via GitBox
