From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: allowing for control over SET ROLE |
Date: | 2022-09-03 19:46:40 |
Message-ID: | b4dc365da19812057b84454c410f6252e33fedc5.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2022-09-03 22:39:20 | Re: Fix typo function circle_same (src/backend/utils/adt/geo_ops.c) |
Previous Message | Tom Lane | 2022-09-03 19:15:34 | Re: Can we avoid chdir'ing in resolve_symlinks() ? |