Repository navigation
revoke excess permissions #298
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.
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
base: master
Are you sure you want to change the base?
Changes from all commits
e89441e
6578515
5831c09
ec49b09
68acdec
6d89518
d623154
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| revoke update on all sequences in schema net to PUBLIC; | ||
|
|
||
| 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; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. same use case as TRUNCATE
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. added delete above with reservation. |
||
| grant delete on net.http_request_queue to PUBLIC; | ||
|
|
||
| revoke truncate on all tables in schema net to PUBLIC; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Sounds fine to me.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, I've seen that as well. Perhaps we should do the same and manage the privileges on |
||
| grant truncate on net.http_request_queue to PUBLIC; | ||
|
|
||
| revoke references on all tables in schema net to PUBLIC; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If there's no PRIMARY or UNIQUE key on the tables then this should be fine
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Per the docs I think this needs to be revoked either way, seems live a vector for a privilege escalation attack:
https://www.postgresql.org/docs/current/ddl-priv.html#DDL-PRIV-REFERENCES
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good call, I agree in revoking this too. |
||
| revoke trigger on all tables in schema net to PUBLIC; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Some users have added triggers in the past #62 (comment)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agree, the case in #62 does self-hosting too so I guess they can use superuser anyway. |
||
| revoke maintain on all tables in schema net to PUBLIC; | ||
|
Comment on lines
+13
to
+14
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This would prevent users from running VACUUM, not sure if needed, it might.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
https://www.postgresql.org/docs/current/ddl-priv.html#DDL-PRIV-MAINTAIN
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wasn't aware of |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are likely not needed, also
insertshouldn't work correctly since #199There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not needed as its okay to revoke and the above statements are fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, should be fine to revoke.