Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost <sfr...@snowman.net> wrote: > > 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.
Just to be clear, we should certainly be thinking about more than just functions but also about things like publications and subscriptions and other bits of the system. I haven't done a detailed analysis quite yet, but I'm reasonably confident that a number of things in this last release cycle have resulted in quite a few additional explicit superuser checks, which I do think is an issue to be addressed. > 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. I agree that it may not be obvious which cases lead to a relatively easy way to obtain superuser and which don't, and that's actually why I'd much rather it be something that we're considering and looking out for because, frankly, we're in a much better position generally to realize those cases than our users are. Further, I agree entirely that we shouldn't be deciding that certain capabilities are never allowed to be given to a user- but that's why superuser *exists* and why it's possible to give superuser access to multiple users. The question here is if it's actually sensible for us to make certain actions be grantable to non-superusers which allow that role to become, or to essentially be, a superuser. What that does, just as it does in the table case, from my viewpoint at least, is make it *look* to admins like they're grant'ing something less than superuser when, really, they're actually giving the user superuser-level access. That violates the POLA because the admin didn't write 'ALTER USER joe WITH SUPERUSER', they just wrote 'GRANT EXECUTE ON lo_import() TO joe;'. We can certainly argue about if the admin should have just known that lo_import()/lo_export() or similar functions were equivilant to grant'ing a user superuser access, but it's not entirely clear to me that it's actually advantageous to go out of our way to provide multiple ways for superuser-level access to be grant'ed out to users. Let's provide one very clear way to do that and strive to avoid building in others, either intentionally or unintentionally. Thanks! Stephen
signature.asc
Description: Digital signature
