* Noah Misch (noah@leadboat.com) wrote:
> On Mon, Nov 24, 2014 at 04:28:46PM -0500, Adam Brightwell wrote:
> > Perhaps this is not an issue but it seemed odd to me, especially after
> > giving Peter's comment more thought. So, I suppose the question is whether
> > or not a superuser check should be added to 'has_rolcatupdate' or not? I
>
> I would not. PostgreSQL has had this feature since day one (original name
> "usecatupd"). It has two use cases, (1) giving effect to non-superuser
> catalog grants and (2) preventing a narrow class of superuser mistakes. We
> wouldn't add such a thing today, but one can safely ignore its existence.
> Making has_rolcatupdate() approve superusers unconditionally would exclude use
> case (2). Neither use case is valuable, but if I had to pick, (2) is more
> valuable than (1).
What's confusing about this is that use-case (2) appears to have been
the intent of the option, but because it's tied directly to superuser
and isn't an independently controllable option, the only way change it
is to do an 'update pg_authid ...'. Even when set that way, it isn't
visible that it's been set through \du, you have to query the catalog
directly.
I wonder if the option had originally been intended to be independent
and *not* given to superusers by default, but because of the concern
about dealing with corrupt systems, etc, it was never actually done.
I'm fine with the line of thinking that says we can't deny superusers
this power because of corruption/debugging concerns, but if that's the
case, then there is no use-case (2) and we should just remove the option
entirely.
I don't buy into use-case (1) above being at all reasonable. With it,
one can trivially make themselves a superuser, and in many ways the
catupdate capability is *more* dangerous than superuser- if you have
catupdate but not superuser, you'd be tempted to hack at the catalog to
make the changes you want instead of using the regular ALTER TABLE, etc,
commands.
Thanks,
Stephen
