From 9918ab62657378dc277441eddc93f0bcdefcd85c Mon Sep 17 00:00:00 2001 From: Classic298 <27028174+Classic298@users.noreply.github.com> Date: Sat, 9 May 2026 16:19:03 +0200 Subject: [PATCH] fix: gate public sharing of skills behind sharing.public_skills on create/update (#24494) 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. Same shape as the calendar fix in #24493, reported by Matteo Panzeri while auditing the resource-cohort cohort during follow-up on #24493. Co-authored-by: Matteo Panzeri <28739806+matte1782@users.noreply.github.com> --- backend/open_webui/routers/skills.py | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/backend/open_webui/routers/skills.py b/backend/open_webui/routers/skills.py index 490d1706d5..ede5afd814 100644 --- a/backend/open_webui/routers/skills.py +++ b/backend/open_webui/routers/skills.py @@ -176,6 +176,19 @@ async def create_new_skill( detail=ERROR_MESSAGES.ID_TAKEN, ) + # Strip public/user grants the requesting user is not permitted to assign + # (matches the channel/notes/calendar pattern). Without this, a user with + # workspace.skills permission could attach principal_id='*' read/write + # grants in the create payload, bypassing the sharing.public_skills gate + # that the dedicated /access/update endpoint already enforces. + form_data.access_grants = await filter_allowed_access_grants( + request.app.state.config.USER_PERMISSIONS, + user.id, + user.role, + form_data.access_grants, + 'sharing.public_skills', + ) + try: skill = await Skills.insert_new_skill(user.id, form_data, db=db) if skill: @@ -276,6 +289,19 @@ async def update_skill_by_id( detail=ERROR_MESSAGES.UNAUTHORIZED, ) + # Strip public/user grants the requesting user is not permitted to assign + # (matches the channel/notes/calendar pattern). The access check above only + # restricts WHO can write to the skill; this filter restricts WHICH grants + # they may set, so a non-admin owner cannot make their own skill publicly + # readable/writable without sharing.public_skills permission. + form_data.access_grants = await filter_allowed_access_grants( + request.app.state.config.USER_PERMISSIONS, + user.id, + user.role, + form_data.access_grants, + 'sharing.public_skills', + ) + try: updated = { **form_data.model_dump(exclude={'id'}),