Robert Haas <robertmh...@gmail.com> writes: > On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost <sfr...@snowman.net> wrote: >> 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. Exactly. I think that Stephen's argument depends on what a black-hat privilege recipient could theoretically do, but fails to consider what's useful for white-hat users. One of the standard rules for careful admins is to do as little as possible as root/superuser. If you have a situation where it's necessary to use, say, lo_import as part of a routine data import task, then the only alternative previously was to do that task as superuser. That is not an improvement, by any stretch of the imagination, over granting lo_import privileges to some otherwise-vanilla role that can run the data import task. We've previously discussed workarounds such as creating SECURITY DEFINER wrapper functions, but I don't think that approach does much to change the terms of the debate: it'd still be better if the wrapper function itself didn't need full superuser. I did miss the need to fix the docs, and am happy to put in some strong wording about the security hazards of these functions while fixing the docs. But I do not think that leaving them with hardwired superuser checks is an improvement over being able to control them with GRANT. 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