Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE - Mailing list pgsql-general

From David G. Johnston
Subject Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
Date
Msg-id CAKFQuwaRd4naNA8Ep2xGrQWp_yGd++xZe9H32PV3G-8o=Dg3nQ@mail.gmail.com
Whole thread Raw
In response to Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE  (Christophe Pettus <xof@thebuild.com>)
List pgsql-general
On Monday, July 8, 2024, Christophe Pettus <xof@thebuild.com> wrote:


> On Jul 8, 2024, at 13:29, Christophe Pettus <xof@thebuild.com> wrote:
>
>
>
>> On Jul 8, 2024, at 13:25, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>> I didn't test it, but doesn't that allow the member rule to drop objects owned
>> be the role it is a member of?
>
> No, apparently not.

Just from a quick check, it looks like you need INHERIT to inherit the ability to drop objects.  The documentation strongly implies this, although it doesn't quite come out and say it.


Are you referring to this:

The right to modify or destroy an object is inherent in being the object's owner, and cannot be granted or revoked in itself. (However, like all privileges, that right can be inherited by members of the owning role; see Section 22.3.)


It can be argued that is more than strong implication though a different more obvious (technical) wording could be in order.

David J.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
Next
From: Pavel Luzanov
Date:
Subject: Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE