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 по дате отправления: