public inbox for [email protected]  

help / color / mirror / Atom feed

From: DINESH  NAIR <[email protected]>
To: Dominique Devienne <[email protected]>
To: Pavel Luzanov <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: Karsten Hilbert <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Q: GRANT ... WITH ADMIN on PG 17
Date: Mon, 25 Aug 2025 18:42:20 +0000
Message-ID: <PN4P287MB43818ADFFE18231855EE1A799C3EA@PN4P287MB4381.INDP287.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CAFCRh--J96OtjyH8ow5bosKy9J7jqQw-gupYhHhP9QTLK-XwaQ@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAFCRh--J96OtjyH8ow5bosKy9J7jqQw-gupYhHhP9QTLK-XwaQ@mail.gmail.com>


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".


INHERIT option should be used in caution to reduce the risk of privilege escalation, especially for sensitive roles:

  *
Set NOINHERIT to TRUE on roles with elevated privileges (e.g., roles that have SUPERUSER, 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 <[email protected]>
Sent: Monday, August 25, 2025 6:08 PM
To: Pavel Luzanov <[email protected]>
Cc: Laurenz Albe <[email protected]>; Karsten Hilbert <[email protected]>; [email protected] <[email protected]>
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 <[email protected]> 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

view thread (4+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Q: GRANT ... WITH ADMIN on PG 17
  In-Reply-To: <PN4P287MB43818ADFFE18231855EE1A799C3EA@PN4P287MB4381.INDP287.PROD.OUTLOOK.COM>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox