Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Andres Freund" <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Daniel Farina" <daniel(at)heroku(dot)com>, "Noah Misch" <noah(at)leadboat(dot)com>
Subject: Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)
Date: 2012-03-28 14:02:21
Message-ID: 22386.1332943341@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Andres Freund <andres(at)anarazel(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-03-28 14:12:31 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Previous Message Simon Riggs 2012-03-28 13:57:40 Re: 9.2 commitfest closure (was Command Triggers, v16)