Re: Changing the setting of wal_sender_timeout per standby

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Changing the setting of wal_sender_timeout per standby
Дата
Msg-id 20180923224047.GA1591@paquier.xyz
обсуждение исходный текст
Ответ на Re: Changing the setting of wal_sender_timeout per standby  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, Sep 23, 2018 at 10:47:44AM -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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

Вложения

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Synchronous replay take III
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options