On Wed, Mar 28, 2012 at 10:02 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> Andres Freund <and...@anarazel.de> wrote: >>> On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote: >>>> As Tom pointed out, if there's another person sharing the user ID >>>> you're using, and you don't trust them, their ability to cancel >>>> your session is likely way down the list of concerns you should >>>> have. > >>> Hm. I don't think that is an entirely valid argumentation. The >>> same user could have entirely different databases. They even could >>> have distinct access countrol via the clients ip. >>> I have seen the same cluster being used for prod/test instances at >>> smaller shops several times. >>> >>> Whether thats a valid usecase I have no idea. > >> Well, that does sort of leave an arguable vulnerability. Should the >> same user only be allowed to kill the process from a connection to >> the same database? > > I don't see a lot of merit in this argument either. If joeseviltwin > can connect as joe to database A, he can also connect as joe to > database B in the same cluster, and then do whatever damage he wants. > > Fundamentally, if two users are sharing the same userid, *they are the > same user* as far as Postgres is concerned. It's just silly to make > protection decisions on the assumption that they might not be. > If a DBA does not like the consequences of that, the solution is > obvious.
I'm coming around to the point of view that we should just make pg_terminate_backend()'s behavior consistent with pg_cancel_backend() and call it good. -- 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
