Skip to content

refactor(db): remove user team provision triggers #2421

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ben-fornefeld wants to merge 2 commits into
base: remove/user-team-provision-triggers
Choose a base branch
from
+183 −0
Open

refactor(db): remove user team provision triggers #2421

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5f9fdf7
refactor(db): remove user team provision triggers
ben-fornefeld Apr 16, 2026
85d6908
Merge branch 'remove/user-team-provision-triggers' into remove/user-t…
ben-fornefeld Apr 16, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
183 changes: 183 additions & 0 deletions packages/db/migrations/20260416120000_remove_user_team_provision_triggers.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,183 @@
-- +goose Up

-- The application now owns auth user projection and default team bootstrap.
-- Remove the legacy database triggers/functions that used to keep public.users
-- in sync and auto-create default teams on signup.

DROP TRIGGER IF EXISTS sync_inserts_to_public_users ON auth.users;
DROP TRIGGER IF EXISTS sync_updates_to_public_users ON auth.users;
DROP TRIGGER IF EXISTS sync_deletes_to_public_users ON auth.users;
DROP TRIGGER IF EXISTS post_user_signup ON public.users;

DROP FUNCTION IF EXISTS public.sync_insert_auth_users_to_public_users_trigger();
DROP FUNCTION IF EXISTS public.sync_update_auth_users_to_public_users_trigger();
DROP FUNCTION IF EXISTS public.sync_delete_auth_users_to_public_users_trigger();
DROP FUNCTION IF EXISTS public.post_user_signup();
DROP FUNCTION IF EXISTS public.extra_for_post_user_signup(uuid, uuid);

DROP POLICY IF EXISTS "Allow to create a new user" ON public.users;
DROP POLICY IF EXISTS "Allow to select a user" ON public.users;
DROP POLICY IF EXISTS "Allow to update a user" ON public.users;
DROP POLICY IF EXISTS "Allow to delete a user" ON public.users;

DROP POLICY IF EXISTS "Allow to create a team to new user" ON public.teams;
DROP POLICY IF EXISTS "Allow to create a user team connection to new user" ON public.users_teams;
DROP POLICY IF EXISTS "Allow to select a team for supabase auth admin" ON public.teams;

REVOKE INSERT ON public.users FROM trigger_user;
REVOKE SELECT (id) ON public.users FROM trigger_user;
REVOKE UPDATE ON public.users FROM trigger_user;
REVOKE DELETE ON public.users FROM trigger_user;

REVOKE SELECT, INSERT, TRIGGER ON public.teams FROM trigger_user;
REVOKE INSERT ON public.users_teams FROM trigger_user;
Copy link
Copy Markdown

@claude claude bot Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The trigger_user role itself is not dropped here. The 20231220094836 migration granted CREATE+USAGE ON SCHEMA public, USAGE ON SCHEMA extensions, and USAGE ON SCHEMA auth to trigger_user - none of which are revoked in this migration. After applying this Up, trigger_user retains schema-level access despite having no functions or triggers. If trigger_user is being fully retired, add REVOKE for the schema grants and DROP ROLE IF EXISTS trigger_user (plus restore in Down).


-- +goose Down
Comment on lines +28 to +35
Copy link
Copy Markdown

@claude claude bot Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 The Up migration revokes trigger_user grants on public.users, public.users_teams, and public.teams, but omits revoking INSERT on public.team_api_keys and public.access_tokens (granted in migration 20231220094836), and does not drop the RLS policies 'Allow to create an access token to new user' and 'Allow to create a team api key to new user' on those same tables. After this PR, trigger_user retains INSERT privileges and active permissive RLS policies on two security-sensitive tables with no remaining code path exercising them — a missed least-privilege cleanup.

Extended reasoning...

What the bug is: The migration explicitly cleans up trigger_user grants and RLS policies on public.users, public.users_teams, and public.teams, but two additional grants and two RLS policies from migration 20231220094836_create_triggers_and_policies.sql are left behind: GRANT INSERT ON public.team_api_keys TO trigger_user, GRANT INSERT ON public.access_tokens TO trigger_user, the policy 'Allow to create an access token to new user' ON public.access_tokens, and the policy 'Allow to create a team api key to new user' ON public.team_api_keys.

Code path that triggered these grants: In 20231220094836_create_triggers_and_policies.sql (lines 17-18), trigger_user was granted INSERT on both tables so the post_user_signup() trigger function could insert default team API keys and access tokens on user signup. The function was later updated in 20240605070918_refactor_triggers_and_policies.sql to explicitly INSERT INTO both tables (lines 67-71), confirming ongoing use. This PR now drops post_user_signup() entirely — the last code path using these privileges.

Why existing code doesn't prevent it: The migration correctly removes the triggers and functions, but the permission cleanup section (lines 28–35 of the new file) only issues REVOKE for public.users, public.users_teams, and public.teams. There are zero REVOKE statements for public.team_api_keys and public.access_tokens across all migrations, and zero DROP POLICY statements targeting the two policies named above. The grants and policies survive the migration untouched.

Impact: After this migration, trigger_user retains INSERT privileges on public.team_api_keys and public.access_tokens — two tables that store credentials and authentication tokens — with no functional trigger or application code path ever invoking those privileges. The retained permissive RLS policies compound the risk: any future code (or SQL injection gaining trigger_user context) could INSERT into these tables and pass RLS unchallenged. This directly contradicts the principle of least privilege that this PR is trying to enforce.

Step-by-step proof:

  1. 20231220094836_create_triggers_and_policies.sql: Issues GRANT INSERT ON public.team_api_keys TO trigger_user and GRANT INSERT ON public.access_tokens TO trigger_user; creates policies 'Allow to create an access token to new user' and 'Allow to create a team api key to new user'.
  2. 20240605070918_refactor_triggers_and_policies.sql: Updates post_user_signup() to INSERT INTO both tables — grants remain in active use.
  3. 20260416120000_remove_user_team_provision_triggers.sql (this PR): Drops post_user_signup() and all three associated triggers. REVOKE block only covers public.users, public.users_teams, and public.teams.
  4. Post-migration state: trigger_user still holds INSERT on public.team_api_keys and public.access_tokens, and both permissive RLS policies remain active — orphaned with no legitimate caller.

How to fix: Add to the Up migration's REVOKE block:

REVOKE INSERT ON public.team_api_keys FROM trigger_user;
REVOKE INSERT ON public.access_tokens FROM trigger_user;
DROP POLICY IF EXISTS "Allow to create a team api key to new user" ON public.team_api_keys;
DROP POLICY IF EXISTS "Allow to create an access token to new user" ON public.access_tokens;

And add corresponding GRANT + CREATE POLICY statements to the Down section for symmetry.

On the duplicate refutation: A refutation claims this duplicates bug_005. While both bugs cover the missing REVOKEs, this bug additionally identifies the two orphaned RLS policies that were never dropped. The policies independently allow trigger_user to pass RLS checks on INSERT — a distinct and additive security surface beyond the raw grants alone. The combined presence of both grants and permissive policies makes this more than a simple REVOKE omission.

Comment on lines +28 to +35
Copy link
Copy Markdown

@claude claude bot Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 The migration revokes all table-level grants from trigger_user but omits the schema-level grants originally issued in 20231220094836_create_triggers_and_policies.sql. After this PR runs, trigger_user still holds CREATE, USAGE on the public schema and USAGE on the extensions and auth schemas — allowing it to create new objects in public despite its entire purpose being retired. Add REVOKE CREATE, USAGE ON SCHEMA public FROM trigger_user; REVOKE USAGE ON SCHEMA extensions FROM trigger_user; REVOKE USAGE ON SCHEMA auth FROM trigger_user; to complete the cleanup.

Extended reasoning...

What the bug is and how it manifests

Migration 20231220094836_create_triggers_and_policies.sql granted trigger_user three schema-level privileges: GRANT CREATE, USAGE ON SCHEMA public TO trigger_user, GRANT USAGE ON SCHEMA extensions TO trigger_user, and GRANT USAGE ON SCHEMA auth TO trigger_user. These were necessary for the role to own and execute trigger functions in those schemas. This PR removes every artifact of that trigger infrastructure (triggers, functions, policies, and table-level grants) but does not revoke these schema-level grants.

The specific code path

Lines 28–35 of the new migration revoke INSERT, SELECT(id), UPDATE, DELETE on public.users, and SELECT, INSERT, TRIGGER on public.teams, and INSERT on public.users_teams. There is no corresponding REVOKE ... ON SCHEMA ... statement anywhere in the Up section or anywhere else in the migration history (a grep for REVOKE.*SCHEMA across all migration files returns no results).

Why existing code doesn't prevent it

PostgreSQL schema-level grants are entirely independent of object-level grants and are not automatically cascaded or cleaned up when object-level grants are revoked. There is no mechanism that automatically removes CREATE ON SCHEMA public just because a role's table grants are revoked. The omission must be corrected explicitly.

Impact

After this migration, trigger_user retains CREATE on the public schema, meaning the role could still create new tables, functions, sequences, or other objects there. It also retains USAGE on extensions and auth schemas. For a role whose sole purpose was owning sync/signup triggers — a purpose this very PR eliminates — these are unnecessary residual privileges. If role credentials were ever compromised or the role were reused, the CREATE privilege represents meaningful attack surface.

How to fix it

Add the following three REVOKE statements to the Up section of the migration (and the corresponding GRANT statements to the Down section, mirroring how the table grants are restored there):

REVOKE CREATE, USAGE ON SCHEMA public FROM trigger_user;
REVOKE USAGE ON SCHEMA extensions FROM trigger_user;
REVOKE USAGE ON SCHEMA auth FROM trigger_user;

Step-by-step proof

  1. Search migration history: 20231220094836_create_triggers_and_policies.sql contains GRANT CREATE, USAGE ON SCHEMA public TO trigger_user, GRANT USAGE ON SCHEMA extensions TO trigger_user, GRANT USAGE ON SCHEMA auth TO trigger_user.
  2. Search all subsequent migrations for REVOKE.*SCHEMA: zero matches found.
  3. The new migration (lines 28–35) revokes only table-level grants — no schema revocations.
  4. After running goose up, SELECT has_schema_privilege('trigger_user', 'public', 'CREATE') still returns true.
  5. trigger_user can now execute CREATE TABLE public.orphan_table (...) successfully, even though every trigger it ever owned has been dropped. The role is orphaned-but-privileged.

-- +goose StatementBegin

GRANT SELECT, INSERT, TRIGGER ON public.teams TO trigger_user;
GRANT INSERT ON public.users_teams TO trigger_user;
GRANT INSERT ON public.users TO trigger_user;
GRANT SELECT (id) ON public.users TO trigger_user;
GRANT UPDATE ON public.users TO trigger_user;
GRANT DELETE ON public.users TO trigger_user;

CREATE POLICY "Allow to create a new user"
ON public.users
AS PERMISSIVE
FOR INSERT
TO trigger_user
WITH CHECK (TRUE);

CREATE POLICY "Allow to select a user"
ON public.users
AS PERMISSIVE
FOR SELECT
TO trigger_user
USING (true);

CREATE POLICY "Allow to update a user"
ON public.users
AS PERMISSIVE
FOR UPDATE
TO trigger_user
USING (true)
WITH CHECK (true);

CREATE POLICY "Allow to delete a user"
ON public.users
AS PERMISSIVE
FOR DELETE
TO trigger_user
USING (true);

CREATE POLICY "Allow to create a team to new user"
ON public.teams
AS PERMISSIVE
FOR INSERT
TO trigger_user
WITH CHECK (TRUE);

CREATE POLICY "Allow to create a user team connection to new user"
ON public.users_teams
AS PERMISSIVE
FOR INSERT
TO trigger_user
WITH CHECK (TRUE);

CREATE POLICY "Allow to select a team for supabase auth admin"
ON public.teams
AS PERMISSIVE
FOR SELECT
TO trigger_user
USING (TRUE);

CREATE OR REPLACE FUNCTION public.extra_for_post_user_signup(user_id uuid, team_id uuid)
RETURNS void
LANGUAGE plpgsql
AS $extra_for_post_user_signup$
DECLARE
BEGIN
END
$extra_for_post_user_signup$ SECURITY DEFINER SET search_path = public;

ALTER FUNCTION public.extra_for_post_user_signup(uuid, uuid) OWNER TO trigger_user;

CREATE OR REPLACE FUNCTION public.post_user_signup()
RETURNS TRIGGER
LANGUAGE plpgsql
AS $post_user_signup$
DECLARE
team_id uuid;
BEGIN
RAISE NOTICE 'Creating default team for user %', NEW.id;
INSERT INTO public.teams(name, tier, email) VALUES (NEW.email, 'base_v1', NEW.email) RETURNING id INTO team_id;
INSERT INTO public.users_teams(user_id, team_id, is_default) VALUES (NEW.id, team_id, true);
RAISE NOTICE 'Created default team for user % and team %', NEW.id, team_id;

PERFORM public.extra_for_post_user_signup(NEW.id, team_id);

RETURN NEW;
END
$post_user_signup$ SECURITY DEFINER SET search_path = public;

ALTER FUNCTION public.post_user_signup() OWNER TO trigger_user;
Copy link
Copy Markdown

@cursor cursor bot Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Down migration restores incomplete post_user_signup function

Medium Severity

The post_user_signup function restored in the Down migration is missing two INSERT statements that exist in the latest production version (defined in 20250106142106_remove_team_is_default.sql): INSERT INTO public.team_api_keys (team_id) and INSERT INTO public.access_tokens (user_id). If this migration is rolled back, new user signups would get a team created but no API key or access token, breaking their ability to use the service.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 5f9fdf7. Configure here.


CREATE OR REPLACE FUNCTION public.sync_insert_auth_users_to_public_users_trigger() RETURNS TRIGGER
LANGUAGE plpgsql
AS $func$
BEGIN
INSERT INTO public.users (id, email)
VALUES (NEW.id, NEW.email);

RETURN NEW;
END;
$func$ SECURITY DEFINER SET search_path = public;

CREATE OR REPLACE FUNCTION public.sync_update_auth_users_to_public_users_trigger() RETURNS TRIGGER
LANGUAGE plpgsql
AS $func$
BEGIN
UPDATE public.users
SET email = NEW.email,
updated_at = now()
WHERE id = NEW.id;

IF NOT FOUND THEN
RAISE EXCEPTION 'User with id % does not exist in public.users', NEW.id;
END IF;

RETURN NEW;
END;
$func$ SECURITY DEFINER SET search_path = public;

CREATE OR REPLACE FUNCTION public.sync_delete_auth_users_to_public_users_trigger() RETURNS TRIGGER
LANGUAGE plpgsql
AS $func$
BEGIN
DELETE FROM public.users WHERE id = OLD.id;
RETURN OLD;
END;
$func$ SECURITY DEFINER SET search_path = public;

ALTER FUNCTION public.sync_insert_auth_users_to_public_users_trigger() OWNER TO trigger_user;
ALTER FUNCTION public.sync_update_auth_users_to_public_users_trigger() OWNER TO trigger_user;
ALTER FUNCTION public.sync_delete_auth_users_to_public_users_trigger() OWNER TO trigger_user;

CREATE TRIGGER sync_inserts_to_public_users
AFTER INSERT ON auth.users
FOR EACH ROW EXECUTE FUNCTION public.sync_insert_auth_users_to_public_users_trigger();

CREATE TRIGGER sync_updates_to_public_users
AFTER UPDATE ON auth.users
FOR EACH ROW EXECUTE FUNCTION public.sync_update_auth_users_to_public_users_trigger();

CREATE TRIGGER sync_deletes_to_public_users
AFTER DELETE ON auth.users
FOR EACH ROW EXECUTE FUNCTION public.sync_delete_auth_users_to_public_users_trigger();

CREATE TRIGGER post_user_signup
AFTER INSERT ON public.users
FOR EACH ROW EXECUTE FUNCTION public.post_user_signup();

-- +goose StatementEnd
Loading