Some questions about schema privileges

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

Responses

Browse pgsql-hackers by date

  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