On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Stephen Frost <sfr...@snowman.net> writes: >> I'm guessing no, which essentially means that *we* consider access to >> lo_import/lo_export to be equivilant to superuser and therefore we're >> not going to implement anything to try and prevent the user who has >> access to those functions from becoming superuser. If we aren't willing >> to do that, then how can we really say that there's some difference >> between access to these functions and being a superuser? > > We seem to be talking past each other. Yes, if a user has malicious > intentions, it's possibly to parlay lo_export into obtaining a superuser > login (I'm less sure that that's necessarily true for lo_import). > That does NOT make it "equivalent", except perhaps in the view of someone > who is only considering blocking malevolent actors. It does not mean that > there's no value in preventing a task that needs to run lo_export from > being able to accidentally destroy any data in the database. There's a > range of situations where you are concerned about accidents and errors, > not malicious intent; but your argument ignores those use-cases.
That will not sound much as a surprise as I spawned the original thread, but like Robert I understand that getting rid of all superuser checks is a goal that we are trying to reach to allow admins to have more flexibility in handling permissions to a subset of objects. Forcing an admin to give full superuser rights to one user willing to work only on LOs import and export is a wrong concept. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers