From: Stephen Frost <sfrost@snowman.net>
To: Adam Brightwell <adam.brightwell@crunchydatasolutions.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: CATUPDATE confusion?
Date: Mon, 29 Dec 2014 20:34:36 -0500
Message-ID: <20141230013435.GI3062@tamriel.snowman.net> (raw)
In-Reply-To: <CAKRt6CTrOf6w5sE5GDRQAJ+JQrfK4h8VM=jVCtiGC+mdFsmXGg@mail.gmail.com>
References: <CAKRt6CQOvT2KiyKg2gFf7h9k8+JVU1149zLb0EXTkKk7TAQGMQ@mail.gmail.com>
<20141227080926.GA2035611@tornado.leadboat.com>
<20141227151034.GU3062@tamriel.snowman.net>
<28382.1419703324@sss.pgh.pa.us>
<20141227231829.GX3062@tamriel.snowman.net>
<1952.1419722762@sss.pgh.pa.us>
<20141227233150.GA2046947@tornado.leadboat.com>
<CAKRt6CTrOf6w5sE5GDRQAJ+JQrfK4h8VM=jVCtiGC+mdFsmXGg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Adam,
* Adam Brightwell (adam.brightwell@crunchydatasolutions.com) wrote:
> Given this discussion, I have attached a patch that removes CATUPDATE for
> review/discussion.
Thanks!
> One of the interesting behaviors (or perhaps not) is how 'pg_class_aclmask'
> handles an invalid role id when checking permissions against 'rolsuper'
> instead of 'rolcatupdate'. This is demonstrated by the
> 'has_table_privilege' regression test expected results. In summary,
> 'has_rolcatupdate' raises an error when an invalid OID is provided,
> however, as documented in the source 'superuser_arg' does not, simply
> returning false. Therefore, when checking for superuser-ness of an
> non-existent role, the result will be false and not an error. Perhaps this
> is OK, but my concern would be on the expected behavior around items like
> 'has_table_privilege'. My natural thought would be that we would want to
> preserve that specific functionality, though short of adding a
> 'has_rolsuper' function that will raise an appropriate error, I'm uncertain
> of an approach. Thoughts?
This role oid check is only getting called in this case because it's
pg_authid which is getting checked (because it's a system catalog table)
and it's then falling into this one case. I don't think we need to
preserve that.
If you do the same query with that bogus OID but a normal table, you get
the same 'f' result that the regression test gives with this change.
We're not back-patching this and I seriously doubt anyone is relying on
this special response for system catalog tables.
So, unless anyone wants to object, I'll continue to look over this patch
for eventual application against master. If there are objections, it'd
be great if they could be voiced sooner rather than later.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
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: sfrost@snowman.net, adam.brightwell@crunchydatasolutions.com, noah@leadboat.com, tgl@sss.pgh.pa.us
Subject: Re: CATUPDATE confusion?
In-Reply-To: <20141230013435.GI3062@tamriel.snowman.net>
* 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