github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-06 03:27:53 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

[PR #2578] [MERGED] fix(labels): fix access-control query leak in label reads (GHSA-hj5c-mhh2-g7jq) #10095

New Issue
Closed
opened 2026-04-23 09:23:42 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-23 09:23:42 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/go-vikunja/vikunja/pull/2578
Author: @tink-bot
Created: 4/9/2026
Status: ✅ Merged
Merged: 4/9/2026
Merged by: @kolaente

Base: main ← Head: fix-label-access-sql-precedence

📝 Commits (2)

  • 6906857 fix(labels): correct broken access-control query for label reads (GHSA-hj5c-mhh2-g7jq)
  • c7711cf fix(labels): derive label max permission from accessible tasks only

📊 Changes

4 files changed (+194 additions, -30 deletions)

View changed files

📝 pkg/db/fixtures/label_tasks.yml (+12 -1)
📝 pkg/db/fixtures/labels.yml (+20 -0)
📝 pkg/models/label_permissions.go (+59 -19)
📝 pkg/models/label_test.go (+103 -10)

📄 Description

hasAccessToLabel chained .Where/.Or/.And on the xorm session, which flattened to WHERE A OR B OR C AND D. Under SQL precedence that evaluates as A OR B OR (C AND D), so the labels.id = ? scope only narrowed one branch — the other two branches leaked every label with any label_tasks row and every label the caller had ever created, regardless of the requested id.

The query is now built with explicit builder.And / builder.Or grouping so the label-id scope wraps the full disjunction. The bogus label_tasks.label_id IS NOT NULL branch is removed, the creator branch is restricted to real user auths, and Exist(ll) becomes Get(ll) so the follow-up Task.CanRead permission computation actually runs; the creator-only path falls back to PermissionRead.

Regression coverage adds fixture label #6 (private, task #34 in project #20) and label #7 (created by user #1, unattached) with explicit allow/deny assertions in TestLabel_ReadOne, and updates TestLabel_ReadAll expectations accordingly.

🔄 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/go-vikunja/vikunja/pull/2578 **Author:** [@tink-bot](https://github.com/tink-bot) **Created:** 4/9/2026 **Status:** ✅ Merged **Merged:** 4/9/2026 **Merged by:** [@kolaente](https://github.com/kolaente) **Base:** `main` ← **Head:** `fix-label-access-sql-precedence` --- ### 📝 Commits (2) - [`6906857`](https://github.com/go-vikunja/vikunja/commit/6906857cfe8fcf216c7394c0b736648c38fe2401) fix(labels): correct broken access-control query for label reads (GHSA-hj5c-mhh2-g7jq) - [`c7711cf`](https://github.com/go-vikunja/vikunja/commit/c7711cf3fa215f0be05e49f954c910818e646ebe) fix(labels): derive label max permission from accessible tasks only ### 📊 Changes **4 files changed** (+194 additions, -30 deletions) <details> <summary>View changed files</summary> 📝 `pkg/db/fixtures/label_tasks.yml` (+12 -1) 📝 `pkg/db/fixtures/labels.yml` (+20 -0) 📝 `pkg/models/label_permissions.go` (+59 -19) 📝 `pkg/models/label_test.go` (+103 -10) </details> ### 📄 Description `hasAccessToLabel` chained `.Where`/`.Or`/`.And` on the xorm session, which flattened to `WHERE A OR B OR C AND D`. Under SQL precedence that evaluates as `A OR B OR (C AND D)`, so the `labels.id = ?` scope only narrowed one branch — the other two branches leaked every label with any `label_tasks` row and every label the caller had ever created, regardless of the requested id. The query is now built with explicit `builder.And` / `builder.Or` grouping so the label-id scope wraps the full disjunction. The bogus `label_tasks.label_id IS NOT NULL` branch is removed, the creator branch is restricted to real user auths, and `Exist(ll)` becomes `Get(ll)` so the follow-up `Task.CanRead` permission computation actually runs; the creator-only path falls back to `PermissionRead`. Regression coverage adds fixture label #6 (private, task #34 in project #20) and label #7 (created by user #1, unattached) with explicit allow/deny assertions in `TestLabel_ReadOne`, and updates `TestLabel_ReadAll` expectations accordingly. --- <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-04-23 09:23:42 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#10095
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?