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 CAAQkdDqXptf4DM0Bf_uryJ5SxSTz8OR9pURuDj6ik-Pux-Az+w@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
List pgsql-bugs
On Mon, Feb 24, 2014 at 2:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If it's possible to extract a principal name from a ticket without
> contacting the server, then that objection fails ... but if that were
> the case then I suppose you'd not be here looking for a solution.

You've got a point. I do believe the principal name is in the ticket
in clear text. I could generate a ticket in anticipation of needing
it, extract the name, and send that. I have no idea how to get it, but
I'll look into it.

I still think this would be useful in the server. If I'm right, and
the principal name is in clear text, the server would look at it this
way:

PSEUDOCODE

// (server receives packet without user, but
// ticket="my ticket for User@REALM.COM")

if(!user_name) {
  if(ticket)
    user_name = extract_user_name(ticket)
}

if(!user_name)
  return NO_USER_NAME;

auth_type = lookup_pg_hba(user_name, database, etc.)

if(ticket) {
  if(auth_type != GSSAPI)
    return BAD_AUTH;

  accept_gssapi_packet(ticket);
}
else {
  // Do what you would normally do
  challenge(auth_type);
}

/PSEUDOCODE

Something like that.

--Brian

pgsql-bugs by date:

Previous
From: Christopher Browne
Date:
Subject: Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
Next
From: Tom Lane
Date:
Subject: Re: BUG #9337: SSPI/GSSAPI with mismatched user names