On Wed, 2022-08-31 at 08:56 -0400, Robert Haas wrote:
> In some circumstances, it may be desirable to control this behavior.
> For example, if we GRANT pg_read_all_settings TO seer, we do want the
> seer to be able to read all the settings, else we would not have
> granted the role. But we might not want the seer to be able to do
> this:
>
> You are now connected to database "rhaas" as user "seer".
> rhaas=> set role pg_read_all_settings;
> SET
> rhaas=> create table artifact (a int);
> CREATE TABLE
> rhaas=> \d
> List of relations
> Schema | Name | Type | Owner
> --------+----------+-------+----------------------
> public | artifact | table | pg_read_all_settings
> (1 row)
Interesting case.
> I have attached a rather small patch which makes it possible to
> control this behavior:
>
> You are now connected to database "rhaas" as user "rhaas".
> rhaas=# grant pg_read_all_settings to seer with set false;
> GRANT ROLE
You've defined this in terms of the mechanics -- allow SET ROLE or not
-- but I assume you intend it as a security feature to allow/forbid
some capabilities.
Is this only about the capability to create objects owned by a role
you're a member of? Or are there other implications?
Regards,
Jeff Davis
