revoke excess permissions by AndrewJackson2020 · Pull Request #298 · supabase/pg_net

AndrewJackson2020 · 2026-09-22T19:51:16Z

Currently pg_net, by default grants all permissions on tables and sequences in net schema. This seems problematic from a security perspective.

pg_cron, for example creates a cron schema but only grants select on the jobs table0, it does not provide usage on the schema even. Instead pg_cron provides documentation for how to provide users access1 via a schema usage grant.

steve-chavez · 2026-09-22T20:26:11Z

+revoke insert on all tables in schema net to PUBLIC;
+revoke update on all tables in schema net to PUBLIC;
+revoke delete on all tables in schema net to PUBLIC;
+revoke truncate on all tables in schema net to PUBLIC;


IIRC this is used sometimes by users to clear the http_request_que rows, if it grows too big I recall there were problems #216

Maybe we can only grant truncate on that one table then? It still seems odd granting that privilege to all as the pg_net queue is a shared resource and you are basically allowing any read only user to clobber everyone elses request.

Maybe we can only grant truncate on that one table then?

Sounds fine to me.

I went ahead and added delete/truncate to public on this table. TBH I still feel a bit weird doing this. pg_cron does not allow usage on the net schema at all by default so the user has to opt into a user being able to use any of the functionality. I wonder if we should do the same.

steve-chavez · 2026-09-22T20:27:32Z

+revoke insert on all tables in schema net to PUBLIC;
+revoke update on all tables in schema net to PUBLIC;


These are likely not needed, also insert shouldn't work correctly since #199

Not needed as its okay to revoke and the above statements are fine?

steve-chavez · 2026-09-22T20:27:44Z

+
+revoke insert on all tables in schema net to PUBLIC;
+revoke update on all tables in schema net to PUBLIC;
+revoke delete on all tables in schema net to PUBLIC;


same use case as TRUNCATE

added delete above with reservation.

steve-chavez · 2026-09-22T20:28:42Z

+revoke delete on all tables in schema net to PUBLIC;
+revoke truncate on all tables in schema net to PUBLIC;
+revoke references on all tables in schema net to PUBLIC;
+revoke trigger on all tables in schema net to PUBLIC;


Some users have added triggers in the past #62 (comment)

This is one again where I would want to consult what the default permissions are. A trigger will essentially highjack another users session with code provided by the client that created the trigger, correct? Seems like this opens up a plethora of security issues.

Agree, the case in #62 does self-hosting too so I guess they can use superuser anyway.

steve-chavez · 2026-09-22T20:29:42Z

+revoke update on all tables in schema net to PUBLIC;
+revoke delete on all tables in schema net to PUBLIC;
+revoke truncate on all tables in schema net to PUBLIC;
+revoke references on all tables in schema net to PUBLIC;


If there's no PRIMARY or UNIQUE key on the tables then this should be fine

Per the docs I think this needs to be revoked either way, seems live a vector for a privilege escalation attack:

Allows creation of a foreign key constraint referencing a table, or specific column(s) of a table. Great care should be taken when granting this privilege, since a user who creates a foreign key can arrange for enforcement of that foreign key to call an arbitrary function, such as a cast function, and such functions will be called with the privileges of the table owner.

https://www.postgresql.org/docs/current/ddl-priv.html#DDL-PRIV-REFERENCES

steve-chavez · 2026-09-22T20:30:21Z

+revoke trigger on all tables in schema net to PUBLIC;
+revoke maintain on all tables in schema net to PUBLIC;


This would prevent users from running VACUUM, not sure if needed, it might.

Not postgres/superuser but obv supabase platform users don't have that anyway. I think what I should do here is validate all of the permissions and only revoke non default permissions that postgres wouldn't grant on a a create table.

This permission would allow any authenticated user to lock the table. Also it seems like it is not a default permission in postgres which leads me to think we should not allow it.

11:22:15 aj@localhost:5432/postgres 96469 =# create table something3 (c1 int); CREATE TABLE 11:22:20 aj@localhost:5432/postgres 96469 =# create user whatever3; CREATE ROLE 11:22:28 aj@localhost:5432/postgres 96469 =# SELECT * FROM has_table_privilege('whatever3', 'something3', 'MAINTAIN') ; has_table_privilege --------------------- f (1 row)

Allows VACUUM, ANALYZE, CLUSTER, REFRESH MATERIALIZED VIEW, REINDEX, LOCK TABLE, and database object statistics manipulation functions (see Table 9.105) on a relation.

https://www.postgresql.org/docs/current/ddl-priv.html#DDL-PRIV-MAINTAIN

steve-chavez · 2026-09-22T21:20:50Z

Not opposed to the changes, but they might be breaking.

AndrewJackson2020 · 2026-09-22T21:22:06Z

Not opposed to the changes, but they might be breaking.

They are absolutely breaking. I think most of the work here is deciding how to handle that.

imor · 2026-09-25T11:32:34Z

@AndrewJackson2020 also bump the version since this PR adds sql/pg_net--0.20.5--0.20.6.sql?

AndrewJackson2020 requested review from imor, steve-chavez and utkarash2991 September 22, 2026 19:51

steve-chavez reviewed Sep 22, 2026

View reviewed changes

AndrewJackson2020 added 6 commits September 23, 2026 11:31

fix: revoke excess permissions

e89441e

fix: fix most tests

6578515

fix: refactor test to use psycopg

5831c09

fix: fix tests, format, convert tests to psycopg

ec49b09

fix: add truncate/delete permission for single table

68acdec

fix: grant truncate

6d89518

AndrewJackson2020 force-pushed the remove_permissions branch from 26879e5 to 6d89518 Compare September 23, 2026 16:32

fix: add checks on delete/truncate

d623154

		revoke insert on all tables in schema net to PUBLIC;
		revoke update on all tables in schema net to PUBLIC;

		revoke trigger on all tables in schema net to PUBLIC;
		revoke maintain on all tables in schema net to PUBLIC;

Uh oh!

Conversation

AndrewJackson2020 commented Sep 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AndrewJackson2020 Sep 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

steve-chavez commented Sep 22, 2026

Uh oh!

AndrewJackson2020 commented Sep 22, 2026

Uh oh!

imor commented Sep 25, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

AndrewJackson2020 Sep 23, 2026 •

edited

Loading