Re: Role Self-Administration

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: Role Self-Administration
Дата
Msg-id 1E0C0DAB-D9DC-4621-8461-90204C55A842@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Role Self-Administration  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Role Self-Administration  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: dfmgr additional ABI version fields
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)