* 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.
In response to
pgsql-bugs by date
|Next:||From: Magnus Hagander||Date: 2009-05-27 20:15:14|
|Subject: Re: BUG #4824: KRB5/GSSAPI authentication fails when user
|Previous:||From: Tom Lane||Date: 2009-05-27 20:06:35|
|Subject: Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal |