Re: BUG #9337: SSPI/GSSAPI with mismatched user names
От | Brian Crowell |
---|---|
Тема | Re: BUG #9337: SSPI/GSSAPI with mismatched user names |
Дата | |
Msg-id | CAAQkdDqXptf4DM0Bf_uryJ5SxSTz8OR9pURuDj6ik-Pux-Az+w@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
|
Список | 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 по дате отправления: