Re: BUG #9337: SSPI/GSSAPI with mismatched user names

Brian Crowell <brian(at)fluggo(dot)com> writes:
> On Mon, Feb 24, 2014 at 3:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If it's possible to get a name out of a ticket without contacting a
>> realm server, I think what you're talking about would likely be all right.

> Well, for starters, it turns out I'm wrong about the principal. Only
> the target principal (that of the Postgres server) is in clear text.
> The source principal (my user name) is in the encrypted part of the
> request, so that can _only_ be decrypted by the server. However, if I
> remember right, the server will be in direct possession of the
> decryption key (IIRC, its own password), and therefore should be able
> to determine the user name without contacting a third server.

Um. I spoke imprecisely, I see. The objection to involving a Kerberos
server in determining the username is not solely about the cycles
involved; it's that it requires identifying a specific Kerberos server
to do it. Don't we lose multi-realm support if we have to know the
server's password in advance of examining pg_hba.conf?

I looked at our docs again and notice that there is no authentication
server specification option for the GSSAPI auth method. I guess that
that information is buried within the "server key file" or someplace;
this goes beyond my knowledge of Kerberos internals I fear. I do see
that there isn't any visible specification of a server password either,
so even absent the multi-realm issue it's not clear to me that what
you propose is practical for code outside the Kerberos libraries.

regards, tom lane