Re: Terminating a rogue connection - Mailing list pgsql-general

From Mark Morgan Lloyd
Subject Re: Terminating a rogue connection
Date
Msg-id juuber$373$1@pye-srv-01.telemetry.co.uk
Whole thread Raw
In response to Re: Terminating a rogue connection  (Chris Angelico <rosuav@gmail.com>)
List pgsql-general
Chris Angelico wrote:
> On Fri, Jul 27, 2012 at 7:09 PM, Mark Morgan Lloyd
> <markMLl.pgsql-general@telemetry.co.uk> wrote:
>> Chris Angelico wrote:
>>> On Fri, Jul 27, 2012 at 6:27 PM, Mark Morgan Lloyd
>>> <markMLl.pgsql-general@telemetry.co.uk> wrote:
>>>> Assuming a *nix server: if a monitoring program determines that an
>>>> established connection appears to be trying to so something
>>>> inappropriate,
>>>> what's the best way of terminating that session rapidly?
>>>
>>> select pg_terminate_backend(procpid) from pg_stat_activity where .....
>>>
>>> The main difficulty is recognizing which PID to terminate, though.
>>
>> Exactly :-)
>>
>> I'd add that this is a hypothetical situation at present, I'm just trying to
>> plan ahead.
>
> Something I've been developing at work lately combines this with
> editing pg_hba.conf to ensure that a kicked connection cannot
> reconnect. Services register themselves with a particular user name,
> then SET USER to switch to the one actual user who owns tables and
> stuff, so my overlording monitor can kick off any service based on IP
> and usename (note the spelling - it's not "username" in the table).
> Rewrite pg_hba.conf, SIGHUP, then pg_terminate_backend in a searched
> SELECT as seen above.
>
> This may be overkill for what you're doing, though. It's part of our
> "prevent split-brain problems" technique.

One problem there is that if somebody is doing something that causes a
significant CPU or memory overcommit, it might be some while before
SIGHUP etc. works. I'm currently eyeballing the Linux capabilities
stuff, it looks as though if a monitor has CAP_NET_ADMIN that it will be
able to temporarily add a firewall rule that blocks the rogue client's
traffic.

I'm hoping to be able to avoid "on the fly" editing of configuration
files, there's too much could go wrong. Which I suppose leads into
another question...

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

pgsql-general by date:

Previous
From: Igor Neyman
Date:
Subject: Re: information_schema.referential_constraints broken?
Next
From: Mark Morgan Lloyd
Date:
Subject: Adding users connection via SSL