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

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 (view raw or flat)
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

pgsql-bugs by date

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

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