[PR #24513] [MERGED] fix: gate tool content updates behind workspace.tools to match create endpoint #98734

New Issue

GiteaMirror · 2026-05-16T01:34:28-05:00

GiteaMirror commented

2026-05-16 01:34:28 -05:00

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-webui/pull/24513
Author: @Classic298
Created: 5/9/2026
Status: ✅ Merged
Merged: 5/10/2026
Merged by: @tjbck

Base: dev ← Head: fix/tools-update-content-workspace-permission

📝 Commits (2)

9c8b8bc fix: gate tool content updates behind workspace.tools to match create endpoint
02aec57 chore: trim comment

📊 Changes

1 file changed (+13 additions, -0 deletions)

View changed files

📝 backend/open_webui/routers/tools.py (+13 -0)

📄 Description

update_tools_by_id (routers/tools.py:452) authorizes a caller as long as they are the tool's owner, hold a write access grant on the tool, or are an admin. This means a verified user who has been given a write grant on a tool — typically as part of a metadata-collaboration workflow (edit description, adjust valves, manage access grants) — can also overwrite the tool's Python source. Because load_tool_module_by_id further down calls exec(content, module.__dict__) at module-import time, anything the new content puts outside the class Tools: body executes immediately on the server with the worker's privileges (root in the default Docker deployment).

The create_new_tools endpoint already requires
workspace.tools (or workspace.tools_import) precisely because creating a tool means submitting executable code. The update endpoint did not mirror that check, producing an asymmetric authorization surface in which a write-grantee with no workspace permission can still reach the same exec sink as a workspace.tools-trusted creator. SECURITY.md frames workspace.tools as the trust signal an admin uses to delegate code-execution capability; the previous behavior let that signal be bypassed by a per-resource share.

Fix: after the existing ownership / write-grant / admin gate, add a content-change check. If form_data.content != tools.content, require workspace.tools or workspace.tools_import (or admin role). Metadata edits — name, description, valves config, access grants — continue to flow through the existing gate, so the legitimate share-for- collaboration workflow is unaffected.

Contributor License Agreement

By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.

Note

Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-webui/pull/24513 **Author:** [@Classic298](https://github.com/Classic298) **Created:** 5/9/2026 **Status:** ✅ Merged **Merged:** 5/10/2026 **Merged by:** [@tjbck](https://github.com/tjbck) **Base:** `dev` ← **Head:** `fix/tools-update-content-workspace-permission` --- ### 📝 Commits (2) - [`9c8b8bc`](https://github.com/open-webui/open-webui/commit/9c8b8bce640aa9db65349628971071a11389867a) fix: gate tool content updates behind workspace.tools to match create endpoint - [`02aec57`](https://github.com/open-webui/open-webui/commit/02aec57cb1e1c1be6afda4a724240ce1a38e2b63) chore: trim comment ### 📊 Changes **1 file changed** (+13 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `backend/open_webui/routers/tools.py` (+13 -0) </details> ### 📄 Description `update_tools_by_id` (routers/tools.py:452) authorizes a caller as long as they are the tool's owner, hold a `write` access grant on the tool, or are an admin. This means a verified user who has been given a write grant on a tool — typically as part of a metadata-collaboration workflow (edit description, adjust valves, manage access grants) — can also overwrite the tool's Python source. Because `load_tool_module_by_id` further down calls `exec(content, module.__dict__)` at module-import time, anything the new content puts outside the `class Tools:` body executes immediately on the server with the worker's privileges (root in the default Docker deployment). The `create_new_tools` endpoint already requires `workspace.tools` (or `workspace.tools_import`) precisely because creating a tool means submitting executable code. The update endpoint did not mirror that check, producing an asymmetric authorization surface in which a write-grantee with no workspace permission can still reach the same exec sink as a workspace.tools-trusted creator. SECURITY.md frames `workspace.tools` as the trust signal an admin uses to delegate code-execution capability; the previous behavior let that signal be bypassed by a per-resource share. Fix: after the existing ownership / write-grant / admin gate, add a content-change check. If `form_data.content != tools.content`, require `workspace.tools` or `workspace.tools_import` (or admin role). Metadata edits — `name`, `description`, valves config, access grants — continue to flow through the existing gate, so the legitimate share-for- collaboration workflow is unaffected. ### Contributor License Agreement  - [x] By submitting this pull request, I confirm that I have read and fully agree to the [Contributor License Agreement (CLA)](https://github.com/open-webui/open-webui/blob/main/CONTRIBUTOR_LICENSE_AGREEMENT), and I am providing my contributions under its terms. > [!NOTE] > Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-05-16 01:34:28 -05:00

GiteaMirror closed this issue

2026-05-16 01:34:30 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#98734