From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Kenaniah Cerny <kenaniah(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: allow database-specific role memberships |
Date: | 2021-10-10 23:45:30 |
Message-ID: | CAKFQuwY0BkSGwHKCbecXOMQeuEXxrwoJyw47zGdx8+i3DHYG-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Oct 10, 2021 at 2:29 PM Kenaniah Cerny <kenaniah(at)gmail(dot)com> wrote:
> In building off of prior art regarding the 'pg_read_all_data' and
> 'pg_write_all_data' roles, I would like to propose an extension to roles
> that would allow for database-specific role memberships (for the purpose of
> granting database-specific privileges) as an additional layer of
> abstraction.
>
> = Problem =
>
> There is currently no mechanism to grant the privileges afforded by the
> default roles on a per-database basis. This makes it difficult to cleanly
> accomplish permissions such as 'db_datareader' and 'db_datawriter' (which
> are database-level roles in SQL Server that respectively grant read and
> write access within a specific database).
>
> The recently-added 'pg_read_all_data' and 'pg_write_all_data' work
> similarly to 'db_datareader' and 'db_datawriter', but work cluster-wide.
>
My first impression is that this is more complex than just restricting
which databases users are allowed to connect to. The added flexibility
this would provide has some benefit but doesn't seem worth the added
complexity.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | kuroda.hayato@fujitsu.com | 2021-10-10 23:51:57 | RE: Question about client_connection_check_interval |
Previous Message | Noah Misch | 2021-10-10 23:43:48 | Re: pgsql: Adjust configure to insist on Perl version >= 5.8.3. |