Re: Q: GRANT ... WITH ADMIN on PG 17
| От | DINESH NAIR |
|---|---|
| Тема | Re: Q: GRANT ... WITH ADMIN on PG 17 |
| Дата | |
| Msg-id | PN4P287MB43818ADFFE18231855EE1A799C3EA@PN4P287MB4381.INDP287.PROD.OUTLOOK.COM обсуждение исходный текст |
| Ответ на | Re: Q: GRANT ... WITH ADMIN on PG 17 (Dominique Devienne <ddevienne@gmail.com>) |
| Список | pgsql-general |
Hi ,
Found this interesting :
"gm-dbo" can manage membership in "gm-doctors" (ADMIN TRUE), but does not inherit
the role's privileges, nor can "gm-dbo" assume the identity of "gm-doctors".
the role's privileges, nor can "gm-dbo" assume the identity of "gm-doctors".
INHERIT option should be used in caution to reduce the risk of privilege escalation, especially for sensitive roles:
- Set
NOINHERITto TRUE on roles with elevated privileges (e.g., roles that haveSUPERUSER,CREATEDB,CREATEROLE, or access to critical data or functions). - Tag such roles as sensitive, and prioritize restricting their inheritance to avoid unintended privilege propagation.
- Enforce role separation by ensuring that users can manage sensitive roles without inheriting their privileges.
Thanks & Regards
Dinesh Nair
From: Dominique Devienne <ddevienne@gmail.com>
Sent: Monday, August 25, 2025 6:08 PM
To: Pavel Luzanov <p.luzanov@postgrespro.ru>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Karsten Hilbert <Karsten.Hilbert@gmx.net>; pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: Re: Q: GRANT ... WITH ADMIN on PG 17
Sent: Monday, August 25, 2025 6:08 PM
To: Pavel Luzanov <p.luzanov@postgrespro.ru>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Karsten Hilbert <Karsten.Hilbert@gmx.net>; pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: Re: Q: GRANT ... WITH ADMIN on PG 17
Caution: This email was sent from an external source. Please verify the sender’s identity before clicking links or opening attachments.
On Mon, Aug 25, 2025 at 2:22 PM Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
>> On 22.08.2025 11:40, Laurenz Albe wrote:
>> Yes, that should work as follows: [...]
> [...] A safer option is to use security definer function to grant membership
FWIW, it's basically what I did.
My primary "admin" application role lost CREATEROLE,
and instead gained EXECUTE on security-definer procs
from a new lower-level role (with CREATEROLE),
in a new separate schema, which does all create/drop
roles or grant/revoke DDLs.
Which has the added benefits to enforce naming conventions for roles,
to enforce grants are only between our "per-DB" roles,
and made it easy to generate an audit-log for all those DDLs.
So the v16 ROLE changes created a BIG MESS for us,
slowing us down quite a bit, but we ended up with a much
better "v2" architecture, so it was not all a loss... YMMV.
So +1 to Pavel. --DD
On Mon, Aug 25, 2025 at 2:22 PM Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
>> On 22.08.2025 11:40, Laurenz Albe wrote:
>> Yes, that should work as follows: [...]
> [...] A safer option is to use security definer function to grant membership
FWIW, it's basically what I did.
My primary "admin" application role lost CREATEROLE,
and instead gained EXECUTE on security-definer procs
from a new lower-level role (with CREATEROLE),
in a new separate schema, which does all create/drop
roles or grant/revoke DDLs.
Which has the added benefits to enforce naming conventions for roles,
to enforce grants are only between our "per-DB" roles,
and made it easy to generate an audit-log for all those DDLs.
So the v16 ROLE changes created a BIG MESS for us,
slowing us down quite a bit, but we ended up with a much
better "v2" architecture, so it was not all a loss... YMMV.
So +1 to Pavel. --DD
В списке pgsql-general по дате отправления: