From: | Anna Akenteva <akenteva(dot)annie(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Some questions about schema privileges |
Date: | 2021-10-20 14:53:02 |
Message-ID: | CACDsxguEgEfm_+yHvkTYwUMMouHr+QAVzELnn_B6VEcfokbTVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
I have been wondering about some things related to schema privileges:
1) Why do visibility rules apply to the \d command, but not to system
tables? What is the purpose of hiding stuff from \d output while users
can get the same info another way?
2) What is the reasoning behind separating schema privileges
specifically into CREATE and USAGE? And is it something that may be
changed in PG in the future?
The current logic allows a situation where after creating a table, a
user is not able to do anything with it despite being the owner. This
can be confusing, and I can't really imagine a scenario where it would
be useful from a security standpoint.
Alternative approaches could be:
- Separating schema privileges into more categories, such as CREATE,
ALTER, DROP, SELECT, UPDATE, INSERT etc, like it was done here [1] for
example. Then it allows more granular control which seems useful for
security.
- To avoid many categories, only have USAGE to fully allow or fully
prohibit someone to do stuff in the schema. Then it at least prevents
the weird situation where a user can create an object but can't do
anything with it.
[1] https://www.ibm.com/docs/en/db2/11.5?topic=privileges-schema
Thank you,
Anna
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2021-10-20 15:19:36 | Re: pgsql: Document XLOG_INCLUDE_XID a little better |
Previous Message | Mark Dilger | 2021-10-20 14:15:25 | Re: pg14 psql broke \d datname.nspname.relname |