[PR #24494] [MERGED] fix: gate public sharing of skills behind sharing.public_skills on create/update #98720

New Issue

GiteaMirror · 2026-05-16T01:33:15-05:00

GiteaMirror commented

2026-05-16 01:33:15 -05:00

📋 Pull Request Information

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

Base: dev ← Head: fix/skills-missing-public-sharing-permission-gate

📝 Commits (1)

09c288e fix: gate public sharing of skills behind sharing.public_skills on create/update

📊 Changes

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

View changed files

📝 backend/open_webui/routers/skills.py (+26 -0)

📄 Description

The /create (L155-193) and /id/{id}/update (L248-297) endpoints in routers/skills.py persisted form_data.access_grants directly to AccessGrants.set_access_grants without filter_allowed_access_grants, while every other shareable resource in the codebase (channels, knowledge, models, notes, prompts, tools, calendars) and the dedicated /id/{id}/access/update endpoint on this same router (L309-348) all do call the filter. A user with workspace.skills permission (default False, but admins can grant it to skill-creating users) could therefore attach {"principal_type":"user","principal_id":"*","permission":"read"|"write"} to the create or update payload and have it persisted unfiltered, bypassing the sharing.public_skills gate that the rest of the cohort enforces.

Two changes:

create_new_skill: call filter_allowed_access_grants with 'sharing.public_skills' immediately before insert, after the existing permission check and ID-taken check.
update_skill_by_id: call filter_allowed_access_grants with the same key after the access check, before form_data.model_dump() flows into Skills.update_skill_by_id. The pre-existing access check at L263-277 only restricts WHO may modify the skill; the new filter restricts WHICH grants they may set.

All supporting plumbing was already in place from prior PRs: filter_allowed_access_grants is already imported at L22, the USER_PERMISSIONS_WORKSPACE_SKILLS_ALLOW_PUBLIC_SHARING constant exists, DEFAULT_USER_PERMISSIONS['sharing']['public_skills'] is wired up, SharingPermissions.public_skills is in the Pydantic, and the admin UI already renders the toggle. This is a pure 2-line router fix that closes the cohort-consistency gap.

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/24494 **Author:** [@Classic298](https://github.com/Classic298) **Created:** 5/9/2026 **Status:** ✅ Merged **Merged:** 5/9/2026 **Merged by:** [@tjbck](https://github.com/tjbck) **Base:** `dev` ← **Head:** `fix/skills-missing-public-sharing-permission-gate` --- ### 📝 Commits (1) - [`09c288e`](https://github.com/open-webui/open-webui/commit/09c288e3a21e70afca2f21d14dcf41040b33359b) fix: gate public sharing of skills behind sharing.public_skills on create/update ### 📊 Changes **1 file changed** (+26 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `backend/open_webui/routers/skills.py` (+26 -0) </details> ### 📄 Description The /create (L155-193) and /id/{id}/update (L248-297) endpoints in routers/skills.py persisted form_data.access_grants directly to AccessGrants.set_access_grants without filter_allowed_access_grants, while every other shareable resource in the codebase (channels, knowledge, models, notes, prompts, tools, calendars) and the dedicated /id/{id}/access/update endpoint on this same router (L309-348) all do call the filter. A user with workspace.skills permission (default False, but admins can grant it to skill-creating users) could therefore attach {"principal_type":"user","principal_id":"*","permission":"read"|"write"} to the create or update payload and have it persisted unfiltered, bypassing the sharing.public_skills gate that the rest of the cohort enforces. Two changes: - create_new_skill: call filter_allowed_access_grants with 'sharing.public_skills' immediately before insert, after the existing permission check and ID-taken check. - update_skill_by_id: call filter_allowed_access_grants with the same key after the access check, before form_data.model_dump() flows into Skills.update_skill_by_id. The pre-existing access check at L263-277 only restricts WHO may modify the skill; the new filter restricts WHICH grants they may set. All supporting plumbing was already in place from prior PRs: filter_allowed_access_grants is already imported at L22, the USER_PERMISSIONS_WORKSPACE_SKILLS_ALLOW_PUBLIC_SHARING constant exists, DEFAULT_USER_PERMISSIONS['sharing']['public_skills'] is wired up, SharingPermissions.public_skills is in the Pydantic, and the admin UI already renders the toggle. This is a pure 2-line router fix that closes the cohort-consistency gap. ### 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:33:15 -05:00

GiteaMirror closed this issue

2026-05-16 01:33:18 -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#98720