psa-systems/mokosh-server
Watch
9
0
Fork
You've already forked mokosh-server
 1
Code Issues Pull requests Projects Releases 10 Packages Wiki Activity Actions

fix(rls): make tenant-isolation GUC count symmetric with owner count #320

Merged
nrupard merged 1 commit from fix/PMS-437-rls-isolation-internal-count-symmetry into main 2026-06-20 17:54:52 +02:00
Conversation 0 Commits 1 Files changed 1 +10 -6
David commented 2026-06-20 17:46:13 +02:00
Owner
Copy link

PMS-414 changed the matching-GUC assertion in rls_isolation to compare against a dynamically captured owner-visible count (tenant_a_companies), which counts every tenant-A company including the internal own-company that PMS-413 migration 062 backfills. Independently, PMS-413 had added a WHERE company_type <> 'internal' filter to the GUC-side count. Merged together these two predicates are asymmetric: the owner count is 2 (probe + internal own-company) while the filtered GUC count is 1, so the assertion fails even though RLS is behaving correctly.

RLS filters purely by tenant_id, not company_type, so the matching GUC legitimately exposes every tenant-A row including the internal own-company (the test comment already states all of these rows must be visible under the matching GUC). Drop the leftover <> 'internal' filter from the GUC count so both sides count the same set; the test still proves fail-closed reads and exact tenant-A visibility.

#PMS-437

PMS-414 changed the matching-GUC assertion in rls_isolation to compare against a dynamically captured owner-visible count (tenant_a_companies), which counts every tenant-A company including the internal own-company that PMS-413 migration 062 backfills. Independently, PMS-413 had added a `WHERE company_type <> 'internal'` filter to the GUC-side count. Merged together these two predicates are asymmetric: the owner count is 2 (probe + internal own-company) while the filtered GUC count is 1, so the assertion fails even though RLS is behaving correctly. RLS filters purely by tenant_id, not company_type, so the matching GUC legitimately exposes every tenant-A row including the internal own-company (the test comment already states all of these rows must be visible under the matching GUC). Drop the leftover `<> 'internal'` filter from the GUC count so both sides count the same set; the test still proves fail-closed reads and exact tenant-A visibility. #PMS-437
fix(rls): make tenant-isolation GUC count symmetric with owner count
Some checks failed
Check / fmt + clippy + compile + unit/doc tests (pull_request) Successful in 58s
Details
E2E / Playwright against staging (pull_request) Failing after 1m1s
Details
Integration / integration tests (pull_request) Successful in 8m23s
Details
Create release / Create release from merged PR (pull_request) Has been skipped
Details
6103ab7c0f 
PMS-414 changed the matching-GUC assertion in rls_isolation to compare against a dynamically captured owner-visible count (tenant_a_companies), which counts every tenant-A company including the internal own-company that PMS-413 migration 062 backfills. Independently, PMS-413 had added a `WHERE company_type <> 'internal'` filter to the GUC-side count. Merged together these two predicates are asymmetric: the owner count is 2 (probe + internal own-company) while the filtered GUC count is 1, so the assertion fails even though RLS is behaving correctly.

RLS filters purely by tenant_id, not company_type, so the matching GUC legitimately exposes every tenant-A row including the internal own-company (the test comment already states all of these rows must be visible under the matching GUC). Drop the leftover `<> 'internal'` filter from the GUC count so both sides count the same set; the test still proves fail-closed reads and exact tenant-A visibility.

#PMS-437
nrupard deleted branch fix/PMS-437-rls-isolation-internal-count-symmetry 2026-06-20 17:54:52 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/mokosh-server!320
No description provided.