* Noah Misch (n...@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
Description: Digital signature