Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] user mapping extension to pg_ident.conf

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Lars Kanis <kanis(at)comcard(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] user mapping extension to pg_ident.conf
Date: 2009-07-21 14:06:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Tue, Jul 21, 2009 at 15:58, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to


pgsql-hackers by date

Next:From: Joshua BrindleDate: 2009-07-21 14:20:09
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193
Previous:From: Tom LaneDate: 2009-07-21 14:03:22
Subject: Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group