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
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 |