On Wed, Jul 22, 2009 at 8:57 AM, Magnus Hagander<magnus@hagander.net> wrote:
> 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.
I believe this means that this patch is rejected, so I am marking it
as such on commitfest.postgresql.org. However, it sounds like there
would be room for a client-side patch offering functionality in this
area, if Lars or someone else wanted to develop such a thing for a
future CommitFest.
Hopefully I've understood the situation correctly...
...Robert