Re: BUG #9337: SSPI/GSSAPI with mismatched user names - Mailing list pgsql-bugs

From Brian Crowell
Subject Re: BUG #9337: SSPI/GSSAPI with mismatched user names
Date
Msg-id CAAQkdDpU8z6KhxyAUROERzzN5HwQqt0LbCSPpQacx+3K83e4OQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #9337: SSPI/GSSAPI with mismatched user names  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #9337: SSPI/GSSAPI with mismatched user names
Next
From: Brian Crowell
Date:
Subject: Re: BUG #9337: SSPI/GSSAPI with mismatched user names