Horton

Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role

Stephen Frost <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2021-06-18T18:45:43Z
Lists: pgsql-bugs 
Greetings,

On Fri, Jun 18, 2021 at 14:37 Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Stephen Frost <sfrost@snowman.net> writes:
> > I haven’t had a chance to delve into this but as far as the question
> above
> > goes- short answer is yes, there was generally an idea that we don’t want
> > policies just disappearing.  Also- we don’t allow a role to be dropped
> when
> > there are GRANT’d privileges, users have to go REVOKE any privileges that
> > reference the role.
>
> But shouldn't DROP OWNED BY clean those out for you?  If you've got
> the right to get rid of the role, ISTM that that should certainly
> include the right to get rid of grants to it.


Ah, yes, I misunderstood what was being suggested … ideally it would just
remove the role from the set and not blow away the entire policy though,
but then that gets to the point about a NONE option as you suggested since
you certainly wouldn’t want that policy to suddenly be as if it was
declared for PUBLIC.

Hrmpf. Makes it a bit awkward as you wouldn’t know, afterwards, what role
that policy HAD been for though.  Perhaps just letting it be removed in
such a case is the better option, if it’s the only role remaining.  That
would be in line with the GRANT system- it’s not like you can review what
ACLs a role had been given after a DROP OWNED BY has been run.

Thanks,

Stephen

>

Commits

  1. Remove unnecessary failure cases in RemoveRoleFromObjectPolicy().

  2. Fix misbehavior of DROP OWNED BY with duplicate polroles entries.