Some questions about schema privileges - Mailing list pgsql-hackers

From Anna Akenteva
Subject Some questions about schema privileges
Date
Msg-id CACDsxguEgEfm_+yHvkTYwUMMouHr+QAVzELnn_B6VEcfokbTVA@mail.gmail.com
Whole thread Raw
Responses Re: Some questions about schema privileges
List 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



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname
Next
From: Dilip Kumar
Date:
Subject: Re: pgsql: Document XLOG_INCLUDE_XID a little better