From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
cc: Noah Misch <noah@leadboat.com>,
 Adam Brightwell <adam.brightwell@crunchydatasolutions.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: CATUPDATE confusion?
In-reply-to: <20141227151034.GU3062@tamriel.snowman.net>
References: 
 <CAKRt6CQOvT2KiyKg2gFf7h9k8+JVU1149zLb0EXTkKk7TAQGMQ@mail.gmail.com>
 <20141227080926.GA2035611@tornado.leadboat.com>
 <20141227151034.GU3062@tamriel.snowman.net>
Comments: In-reply-to Stephen Frost <sfrost@snowman.net>
 message dated "Sat, 27 Dec 2014 10:10:34 -0500"
Date: Sat, 27 Dec 2014 13:02:04 -0500
Message-ID: <28382.1419703324@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Stephen Frost <sfrost@snowman.net> writes:
> * 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,

Yes.  Noah's claim that anybody intended (1) seems to be mere historical
revisionism, especially since as you note CATUPDATE could be trivially
parlayed into superuser if someone were to grant it to a non-superuser.

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

This is not hard to understand either: the option dates from long before
there was any concerted effort to invent bespoke SQL commands for every
interesting catalog manipulation.  If CATUPDATE had any significant use,
we'd have extended ALTER USER (and \du, and pg_dump ...) at some point
to make it more easily controllable.  But since it's of such marginal
usefulness, nobody ever bothered; and I doubt we should bother now.

In short, I agree with Noah's conclusion (do nothing) though not his
reasoning.

Plan C (remove CATUPDATE altogether) also has some merit.  But adding a
superuser override there would be entirely pointless.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers