Exactly! Vulnerability is the direct analogy of one with Unix shell. The way we generally deal with Unix shell vulnerability, we configure the shell to terminate on its own if timeout was exceeded. The question here is, can we configure psql client to behave the same?
Thanks,
Oleg
On Sun, Dec 20, 2015 at 1:38 PM, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
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
