On Wed, Mar 28, 2012 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Andres Freund <andres@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