Re: BUG #9337: SSPI/GSSAPI with mismatched user names
От | Brian Crowell |
---|---|
Тема | Re: BUG #9337: SSPI/GSSAPI with mismatched user names |
Дата | |
Msg-id | CAAQkdDpU8z6KhxyAUROERzzN5HwQqt0LbCSPpQacx+3K83e4OQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #9337: SSPI/GSSAPI with mismatched user names (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #9337: SSPI/GSSAPI with mismatched user names
Re: BUG #9337: SSPI/GSSAPI with mismatched user names Re: BUG #9337: SSPI/GSSAPI with mismatched user names |
Список | pgsql-bugs |
On Mon, Feb 24, 2014 at 12:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If we did that, wouldn't it mean that anyone with a working Kerberos login > could log in as *any* database user? Even a superuser? > > I'm prepared to grant that we might need to change the behavior somehow, > but it seems like not requiring any connection at all between the Kerberos > principal name and the database user name would be entirely unsafe. I don't think I'm suggesting what you're thinking. I'm saying that if the Postgres user name *has* to match the Kerberos principal name anyways, why not just take the Kerberos principal name and save us the trouble of sending a Postgres user name? Right now, I'm seeing log entries like this: 2014-02-24 11:30:40 CST LOG: provided user name (Brian) and authenticated user name (BCrowell@REALM.COM) do not match But the Kerberos ticket is perfectly valid, and matches a Postgres user. In this case, the program attempting to log in is incapable of determining the correct Postgres user name to send (see Npgsql bug for the dirty details), so why not just accept the Kerberos principal name? --Brian
В списке pgsql-bugs по дате отправления: