Date: Fri, 18 Jun 2021 15:25:55 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
	exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on
 DROP OWNED policy applied to duplicate role
Message-ID: <202106181925.x6ka3pktyblk@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAOuzzgpmUhyS4T3bG7+rtF7ZLPd0kp+-piCengitHdMN1-PHLg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202106181925.x6ka3pktyblk%40alvherre.pgsql>
Precedence: bulk

On 2021-Jun-18, Stephen Frost wrote:

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

Could you just set the policy to be granted to "only the bootstrap
superuser" in that case?  I mean as an implementation path for back
branches; use NONE going forward.  That would make the policy allow
nobody who can't already access the record, instead of falling back to
PUBLIC -- which I agree seems suboptimal security-wise.

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

Yeah, I think if you really wanted to keep track of changes, you would
have an auditing system that records them.  Pity you can't build one
with event triggers (because these don't work for global objects).

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
"No hay hombre que no aspire a la plenitud, es decir,
la suma de experiencias de que un hombre es capaz"