fix(db): relocate postgis to the extensions schema to clear spatial_ref_sys lint#112
Merged
Merged
Conversation
…ef_sys lint public.spatial_ref_sys trips the Supabase advisor's rls_disabled_in_public (0013) but is owned by the PostGIS extension, so postgres can neither enable RLS on it nor revoke supabase_admin's grants. The supported fix is moving the whole extension out of public (also clearing extension_in_public, 0014): the extensions schema is hard-excluded by the linter and not exposed via PostgREST. PostGIS >= 2.3 refuses ALTER EXTENSION ... SET SCHEMA, so migration 20260610_1000 applies the PostGIS-project recipe (flip extrelocatable, SET SCHEMA, dummy UPDATE TO "ANY" + UPDATE to rewrite internal refs) where it can, in three convergent branches: - already relocated / not installed: no-op (prod after the Supabase support ticket; fresh projects using the dashboard default schema) - in public + superuser (docker compose, both CI postgis containers): run the recipe and persist search_path = "$user", public, extensions so unqualified ST_* calls and future geometry DDL keep resolving (Supabase already ships that search_path) - in public + not superuser (Supabase today): warn and no-op so deploys never break; the relocation itself must be run by Supabase support per their docs docs/POSTGIS-SCHEMA-RELOCATION.md carries the audit, the prod runbook, and validation evidence. conftest now disposes the engine pool after upgrade head so no pooled test connection keeps a pre-relocation search_path. Validated against an ephemeral postgis/postgis:16-3.5 container (amd64, :55432): image-default DB with topology/tiger preinstalled, fresh DB from template1, downgrade/re-upgrade cycle, non-superuser Supabase simulation, and the full integration suite (325 passed) against the relocated DB.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves the last two Supabase security advisor findings on project
qijajhckwxsclvyzeaez:rls_disabled_in_public(0013) onpublic.spatial_ref_sysandextension_in_public(0014) on postgis — the documented known limitation left open by #111.spatial_ref_sysis owned by the PostGIS extension (supabase_adminon Supabase), sopostgrescan neither enable RLS on it nor revoke the API-role grants. The supported fix is relocating the whole extension to theextensionsschema, which the advisor hard-excludes and PostgREST does not expose.PostGIS ≥ 2.3 refuses
ALTER EXTENSION … SET SCHEMA, so the new migration20260610_1000applies the recipe published by the PostGIS project (and reproduced in Supabase's postgis docs): flippg_extension.extrelocatable,SET SCHEMA extensions, then a dummyUPDATE TO "ANY"+UPDATEto rewrite internal schema-qualified references. Three convergent branches:public+ superuser (docker compose, both CI postgis containers) → run the recipe and persistsearch_path = "$user", public, extensionsso unqualifiedST_*calls and futuregeometryDDL keep resolving (Supabase already ships that search_path)public+ not superuser (Supabase today) → warn loudly and no-op sorailway-start.shdeploys never break; per Supabase's own docs the prod relocation must be run by their support team (runbook indocs/POSTGIS-SCHEMA-RELOCATION.md)Audit found a single geometry column (
nws_alerts.geometry— OID-based, survives the move untouched) and runtime-onlyST_*usage inaeroza/query/alerts.pyandaeroza/push/dispatch.py, all covered by the search_path handling.tests/conftest.pynow disposes the engine pool afterupgrade headso no pooled test connection keeps a pre-relocation search_path.Test plan
postgis/postgis:16-3.5(linux/amd64, :55432), image-default DB with topology/tiger preinstalled inpublic:alembic upgrade headrelocates; extension inextensions,spatial_ref_sys8500 rows, geometry typmod + GIST index intact, unqualifiedST_AsGeoJSON/ST_Intersectsround trip on a fresh connectionalembic downgrade -1returns postgis topublicand resets search_path; re-upgrade relocates againtemplate1(CI integration-job path): fullupgrade headinstalls then relocates in one runpublic): upgrade reaches head with a warning, postgis untouched, no failurepytest -m integrationagainst the relocated DB: 325 passedmake checkgreen (ruff, format, 519 unit tests)docs/POSTGIS-SCHEMA-RELOCATION.md, then re-run the advisor