Re: Role Self-Administration - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Role Self-Administration
Date
Msg-id 1E0C0DAB-D9DC-4621-8461-90204C55A842@enterprisedb.com
Whole thread Raw
In response to Re: Role Self-Administration  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Role Self-Administration
List pgsql-hackers

> On Oct 7, 2021, at 9:05 AM, Stephen Frost <sfrost@snowman.net> wrote:
>
>> Hmmph.  I think it would be strange if all of the following were true:
>>
>> 1) DROP ROLE bob CASCADE drops all objects owned by bob
>> 2) Roles can own other roles
>> 3) DROP ROLE bob CASCADE never cascades to other roles
>>
>> I'm assuming you see the inconsistency in that set of rules.  So, one of them must be wrong.  You've just replied
thatthe spec is mute on the subject of #1.  Is there any support in the spec for claiming that #2 is wrong? 
>
> Pretty sure I mentioned this before, but the spec doesn't seem to really
> say anything about roles owning other roles, so #2 isn't part of the
> spec.

Regulations and specifications are usually thought about as either "permissive" or "prohibitory".  Permissive rules
allowanything that isn't expressly prohibited.  Prohibitive rules prohibit anything that isn't explicitly permitted.
I'mtaking the SQL spec to be a permissive set of rules.  

I'm reasonable enough to concede that even if something is not explicitly prohibited, it is still effectively
prohibitedif it cannot be done without also doing some other thing that is prohibited.  

From your statements, I take it that #2 is allowed, at least if it doesn't necessarily lead to some other violation.
Sotentatively, I conclude that roles may own other roles. 

> #1 also isn't supported by the spec from what I can see.

From that, I tentatively conclude that #1 is allowed, though I am aware that you may argue that it necessarily violates
thisnext thing... 

> When the statement is:
>
> DROP ROLE bob;
>
> or
>
> DROP ROLE bob RESTRICT;
>
> then the command "REVOKE bob FROM A RESTRICT;" is supposed to be run BUT
> is supposed to throw an exception if there are "any dependencies on the
> role."

Yeah, I don't think my proposal violates this.

> If the statement is:
>
> DROP ROLE bob CASCADE;
>
> then the command "REVOKE bob FROM A CASCADE;" is run and shouldn't throw
> an exception.

Right, and this will be run.  It's just that other stuff, like dropping owned objects, will also be run.  I'm not
seeinga prohibition here, just a mandate, and the proposal fulfills the mandate. 

> I don't think the spec supports any of the three rules you list.

And I'm not seeing that it prohibits any of them.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: dfmgr additional ABI version fields
Next
From: Robert Haas
Date:
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)