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

From Magnus Hagander
Subject Re: [PATCH] user mapping extension to pg_ident.conf
Date
Msg-id 9837222c0907220203ie555262qb0c5be81cabd3318@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] user mapping extension to pg_ident.conf  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] user mapping extension to pg_ident.conf
List pgsql-hackers
On Tue, Jul 21, 2009 at 16:06, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> 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.

That was the core problem, yes. IIRC there were some other minor
issues with it as well.


>> 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.

"challenge type"? Not sure I understand what you are referring to here.


-- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Laurent Laborde
Date:
Subject: Re: Higher TOAST compression.
Next
From: Andreas Wenk
Date:
Subject: Re: psql - small fix in \du