Re: Terminating a rogue connection
| От | Mark Morgan Lloyd |
|---|---|
| Тема | Re: Terminating a rogue connection |
| Дата | |
| Msg-id | juuber$373$1@pye-srv-01.telemetry.co.uk обсуждение |
| Ответ на | Re: Terminating a rogue connection (Chris Angelico <rosuav@gmail.com>) |
| Список | 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 по дате отправления: