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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-22 12:57:55
Message-ID: 9837222c0907220557t721a2237y4d5cb81be7bb0398@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 22, 2009 at 14:53, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-22 13:16:20 Re: Upgrading our minimum required flex version for 8.5
Previous Message Tom Lane 2009-07-22 12:53:47 Re: [PATCH] user mapping extension to pg_ident.conf