Re: [PATCH] user mapping extension to pg_ident.conf
От | Magnus Hagander |
---|---|
Тема | Re: [PATCH] user mapping extension to pg_ident.conf |
Дата | |
Msg-id | 9837222c0907220557t721a2237y4d5cb81be7bb0398@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] user mapping extension to pg_ident.conf (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] user mapping extension to pg_ident.conf
|
Список | pgsql-hackers |
On Wed, Jul 22, 2009 at 14:53, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >>> Yup, you would need a protocol change that would allow the client to >>> change its mind about what the username was after it got the auth >>> challenge. And then what effects does that have on username-sensitive >>> pg_hba.conf decisions? We go back and change our minds about the >>> challenge type, perhaps? The whole thing seems like a nonstarter to me. > >> "challenge type"? Not sure I understand what you are referring to here. > > The point is that pg_hba.conf allows the selection of auth method to > depend on username. What happens if, after being told auth method is > (say) Kerberos, the client comes back and wants to use a different > username that should have resulted in a different auth method according > to pg_hba.conf? It's not hard to construct scenarios where that would > be seen as a security breach. Oh. Now I get it. Good point. Forgot about the username being part of that. Yeah, that basicalliy says it has to be a client-side implementation only. -- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: