Re: Changing the setting of wal_sender_timeout per standby

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, 'Masahiko Sawada' <sawada(dot)mshk(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Changing the setting of wal_sender_timeout per standby
Date: 2018-09-23 22:40:47
Message-ID: 20180923224047.GA1591@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Sep 23, 2018 at 10:47:44AM -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> Have there been discussions about the security effects of this change?
>> Previously the server admin could control the timeout, which could
>> affect things like syncrep, after this it's not possible anymore. I
>> *think* that's ok, but it should be discussed.
>
> Hm. An evil replication connection could already cause all sorts of
> operational problems (and I'm not counting grabbing all your data).
> Does this add anything much new in that line? It seems like the
> effects would be at least in the same ballpark as not sending
> hot-standby-feedback messages in a timely fashion.

Well, a user able to spawn a WAL sender has replication rights, and it
is already entrusted a lot, particularly knowing that this user can run
BASE_BACKUP and fetch a superuser password which could be used for more
evil actions. So I am not sure what is actually worrying with this
change in this area, at least it seems to me that the bar is not really
lowered. An admin can still enforce a value if the client does not
specify it at connection time. What kind of attack would you see? An
evil user connecting with a insanely high value and delaying failure
detection, impacting the system performance?
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-09-23 23:10:25 Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Previous Message Thomas Munro 2018-09-23 22:39:18 Re: Synchronous replay take III