Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal - Mailing list pgsql-bugs

From Stephen Frost
Subject Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Date
Msg-id 20090527201031.GV8123@tamriel.snowman.net
Whole thread Raw
In response to Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Peter Koczan <pjkoczan@gmail.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?
>=20
> 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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Next
From: Magnus Hagander
Date:
Subject: Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal