On Wed, Jul 22, 2009 at 8:57 AM, Magnus Hagander<mag...@hagander.net> wrote: > On Wed, Jul 22, 2009 at 14:53, Tom Lane<t...@sss.pgh.pa.us> wrote: >> Magnus Hagander <mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
