On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost <sfr...@snowman.net> wrote: >> I disagree that that is, or should be, a guiding principle. > > It was what I was using as the basis of the work which I did in this > area and, at least at that time, there seemed to be little issue with > that.
Well, there actually kind of was. It came up here: http://postgr.es/m/ca+tgmoy6ne5n4jc5awxser2g2gdgr4omf7edcexamvpf_jq...@mail.gmail.com I mis-remembered who was on which side of the debate, though, hence the comment about employers. But never mind about that, since I was wrong. Sorry for not checking that more carefully before. > This is not unlike the discussions we've had in the past around allowing > non-owners of a table to modify properties of a table, where the > argument has been successfully and clearly made that if you make the > ability to change the table a GRANT'able right, then that can be used to > become the role which owns the table without much difficulty, and so > there isn't really a point in making that right independently > GRANT'able. We have some of that explicitly GRANT'able today due to > requirements of the spec, but that's outside of our control. I don't think it's quite the same thing. I wouldn't go out of my way to invent grantable table rights that just let you usurp the table owner's permissions, but I still think it's better to have a uniform rule that functions we ship don't contain hard-coded superuser checks. One problem is that which functions allow an escalation to superuser that is easy enough or reliable enough may not actually be a very bright line in all cases. But more than that, I think it's a legitimate decision to grant to a user a right that COULD lead to a superuser escalation and trust them not to use that way, or prevent them from using it that way by some means not known to the database system (e.g. route all queries through pgbouncer and send them to a teletype; if a breach is detected, go to the teletype room, read the paper contained therein, and decide who to fire/imprison/execute at gunpoint). It shouldn't be our job to decide that granting a certain right is NEVER ok. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers