Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Koczan <pjkoczan(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Date: 2009-05-27 20:10:31
Message-ID: 20090527201031.GV8123@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Peter Koczan <pjkoczan(at)gmail(dot)com> writes:
> > This is trust authentication with one rather inconsequential bit of
> > verification, that's a fundamental breakage. One of the major points
> > of Kerberos is that, for anything that talks Kerberos, you are the
> > principal in that ticket. I understand the desire to change some of
> > that old code, but why is that principal being ignored?
>
> Well, the reason for that change was that the libpq code was absorbing
> userid from any available Kerberos ticket, even if the server
> subsequently issued a non-Kerberos authentication challenge. I still
> think that was wrong. What your complaint seems to suggest is that
> the server-side Kerberos auth code should be insisting that the supplied
> principal's first component match the requested database userid.
> I kinda thought we *had* been doing that, but can't claim to have read
> that code closely. Magnus?

We should certainly either be requiring the princ match the user in the
database, or that it is allowed through a username mapping where a
mapping table has been supplied, ala ident.

Stephen

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Magnus Hagander 2009-05-27 20:15:14 Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Previous Message Tom Lane 2009-05-27 20:06:35 Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal