Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal
От | Stephen Frost |
---|---|
Тема | Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal |
Дата | |
Msg-id | 20090527201031.GV8123@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: