Re: Session Identifiers

Поиск
Список
Период
Сортировка
От Andrew Sullivan
Тема Re: Session Identifiers
Дата
Msg-id 20151220193842.GA11123@crankycanuck.ca
обсуждение исходный текст
Ответ на Re: Session Identifiers  (oleg yusim <olegyusim@gmail.com>)
Ответы Re: Session Identifiers  (oleg yusim <olegyusim@gmail.com>)
Список pgsql-general
On Sun, Dec 20, 2015 at 11:25:45AM -0600, oleg yusim wrote:
> Thanks you very much Melvin, once again, very useful. So, let me see if I
> got it right, following configuration should cause my database connection
> to terminate in 15 minutes, right?
>
> tcp_keepalives_idle = 900
> tcp_keepalives_interval=1
> tcp_keepalives_count=3

Only if your psql session ends.  Psql is a client program.  It keeps
its connection to the database alive.

In this sense, the vulnerability you're looking at is analagous to the
case where someone logs into a UNIX shell and then leaves the shell
open.  If the system can be compromised such that someone else can get
control of that shell, you have a problem.  Otherwise, the session
can't really be taken over.  So, your exposure is exactly as great as
the exposure from UNIX process takeover.

You can prove to yourself that the process doesn't linger by opening
up a TCP connection (or for that matter a UNIX socket connection) and
somehow making the containing program fail (e.g. open a psql
connection and then sever your connection to the machine that had the
shell that initiated the psql session, without properly closing the
shell so that the session hangs around).  Eventually, the Postgres
backend will try to talk to the session and discover it isn't there,
and you'll get a termination logged (assuming you have loging turned
up that high).

A

--
Andrew Sullivan
ajs@crankycanuck.ca


В списке pgsql-general по дате отправления:

Предыдущее
От: Félix GERZAGUET
Дата:
Сообщение: Test disk reliability (or HGST HTS721010A9E630 surprisingly reliable)
Следующее
От: oleg yusim
Дата:
Сообщение: Re: Session Identifiers