Skip to content

fix(amber, v1.2): guard cloneWorkflow with a read-access check - #7625

Closed
github-actions[bot] wants to merge 1 commit into
release/v1.2from
backport/7605-guard-cloneworkflow-with-a-read-access-c-v1.2
Closed

fix(amber, v1.2): guard cloneWorkflow with a read-access check#7625
github-actions[bot] wants to merge 1 commit into
release/v1.2from
backport/7605-guard-cloneworkflow-with-a-read-access-c-v1.2

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

What changes were proposed in this PR?

Automated backport of #7605 to release/v1.2.

Source: 2891897 · automation run

Any related issues, documentation, discussions?

Backport of #7605.

How was this PR tested?

Release-branch CI runs on this branch once the conflicts are resolved and this PR is marked ready for review.

Was this PR authored or co-authored using generative AI tooling?

No.

### 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?

(backported from commit 2891897)

Generated-by: Claude Code (Opus 5)
@github-actions

Copy link
Copy Markdown
Contributor Author

The cherry-pick conflicted and was committed with conflict markers. Resolve the conflicts on this branch, then mark this PR ready for review.

Conflicting files:

  • amber/src/test/scala/org/apache/texera/web/resource/dashboard/file/WorkflowResourceSpec.scala

@aglinxinyuan

Copy link
Copy Markdown
Contributor

May not be a fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant