Re: [PATCH] user mapping extension to pg_ident.conf - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] user mapping extension to pg_ident.conf
Date
Msg-id 11898.1248185217@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] user mapping extension to pg_ident.conf  (Magnus Hagander <magnus@hagander.net>)
Responses Re: [PATCH] user mapping extension to pg_ident.conf  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Jul 21, 2009 at 15:58, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> Are you not describing a behavior that you yourself removed in 8.4,
>> ie the libpq code that looked aside at Kerberos for a username?

> Yes, partially I am :-)

> But it was not documented, and done in a fairly hackish way. If we
> want it, it should work the same for *all* external authentication
> methods (where it would be possible).

Well, the problem with it of course was that it happened even when the
selected auth method was not Kerberos.

> Doing it on the client presents a certain challenge

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex
Next
From: Joshua Brindle
Date:
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193