On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost <sfr...@snowman.net> wrote: > 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.
I disagree. It's flattering to imagine that PostgreSQL developers, as a class, are smarter than PostgreSQL users, but it doesn't match my observations. > 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;'. This is exactly the kind of thing that I'm talking about. Forcing an administrator to hand out full superuser access instead of being able to give just lo_import() makes life difficult for users for no good reason. The existence of a theoretically-exploitable security vulnerability is not tantamount to really having access, especially on a system with a secured logging facility. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
