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
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 |