From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Noah Misch <noah@leadboat.com>
Cc: Adam Brightwell <adam.brightwell@crunchydatasolutions.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: CATUPDATE confusion?
Date: Sat, 27 Dec 2014 13:02:04 -0500
Message-ID: <28382.1419703324@sss.pgh.pa.us> (raw)
In-Reply-To: <20141227151034.GU3062@tamriel.snowman.net>
References: <CAKRt6CQOvT2KiyKg2gFf7h9k8+JVU1149zLb0EXTkKk7TAQGMQ@mail.gmail.com>
<20141227080926.GA2035611@tornado.leadboat.com>
<20141227151034.GU3062@tamriel.snowman.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, sfrost@snowman.net, noah@leadboat.com, adam.brightwell@crunchydatasolutions.com
Subject: Re: CATUPDATE confusion?
In-Reply-To: <28382.1419703324@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox