Re: Session Identifiers - Mailing list pgsql-general

From Andrew Sullivan
Subject Re: Session Identifiers
Date
Msg-id 20151220193842.GA11123@crankycanuck.ca
Whole thread Raw
In response to Re: Session Identifiers  (oleg yusim <olegyusim@gmail.com>)
Responses Re: Session Identifiers  (oleg yusim <olegyusim@gmail.com>)
List 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 by date:

Previous
From: Félix GERZAGUET
Date:
Subject: Test disk reliability (or HGST HTS721010A9E630 surprisingly reliable)
Next
From: oleg yusim
Date:
Subject: Re: Session Identifiers