Re: allowing for control over SET ROLE

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-09-03T19:46:40Z
Lists: pgsql-hackers
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




Commits

  1. More documentation update for GRANT ... WITH SET OPTION.

  2. Restrict the privileges of CREATEROLE users.

  3. Add support for GRANT SET in psql tab completion

  4. Add a SET option to the GRANT command.

  5. Allow grant-level control of role inheritance behavior.