Re: [HACKERS] SCRAM auth and Pgpool-II

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] SCRAM auth and Pgpool-II
Дата
Msg-id CAB7nPqSaKjOF=o3K+zhApvBqhYksz-do=pHOa-Vc8rrmjTCOTw@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] SCRAM auth and Pgpool-II  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Ответы Re: [HACKERS] SCRAM auth and Pgpool-II  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Re: [HACKERS] SCRAM auth and Pgpool-II  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Jul 6, 2017 at 10:03 AM, Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
> For Pgpool-II, things would go as follows:
>
> 1) clients sends user name to Pgpool-II.
> 2) Pgpool-II forwards it to PostgreSQL servers.
> 3) Each PostgreSQL server sends their own salt to Pgpool-II.
> 4) Pgpool-II is confused because there are multiple salts and each has
>    different values. The client only accepts single salt obviously.

Couldn't you cache one single SASL exchange status for each
connection, meaning one PGconn saved for each? As the challenge sent
by the server and the response generated by the client are different
by design, I am afraid you would need to do that anyway in this
context (Isn't PG-pool using already the weaknesses of MD5 to make
things easier?). As the server decides first which authentication type
should happen before beginning the real message exchange, that should
not be difficult. It seems to me that you would need something more
modular than you have now if you want for example to handle
automatically connections to multiple servers that have different
password hashes stored for the same user. The latter may be an edge
case with pgpool though.
-- 
Michael



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Suspicious place in heap_prepare_freeze_tuple()
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] SCRAM auth and Pgpool-II