Re: WIP: SCRAM authentication
От | Michael Paquier |
---|---|
Тема | Re: WIP: SCRAM authentication |
Дата | |
Msg-id | CAB7nPqTLM-ZKz_xn+HXJ=QyK7j+eku3JrxqYvvhUW_g4MQLrAQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: SCRAM authentication (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: WIP: SCRAM authentication
|
Список | pgsql-hackers |
On Mon, Feb 15, 2016 at 10:51 AM, Stephen Frost <sfrost@snowman.net> wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> Stephen Frost <sfrost@snowman.net> writes: >> > Why do we need pg_shadow or pg_user or related views at all..? >> >> A lot of code looks at those just to get usernames. I am not in favor of >> breaking such stuff without need. > > Alright. > >> How about we just say that the password in these old views always reads >> out as '********' even when there is a password, and we invent new views >> that carry real auth information? (Hopefully in an extensible way.) > > I'd be alright with that approach, I'd just rather that any clients > which actually want to read the password field be updated to look at the > extensible and sensible base catalogs, and not some hacked up array that > we shoved into that field. Well, then let's mask it, and just have pg_auth_verifiers. Another possible problem that I can see with this patch is what do we do with valid_until? The last set of patches sent did not switch this field to be per-verifier settable. I would consider a saner approach to keep things simple and still do that. Allowing multiple verifiers per protocol is a problem, and having a solution for it would be nice. Should this be prioritized before having more protocols like SCRAM? FWIW, browsing through pgbouncer, it has a look at pg_shadow for user's password to build a basic configuration file. (My mistake, while pg_user is world-readable, that's not the case of pg_shadow). -- Michael
В списке pgsql-hackers по дате отправления: