Re: BUG #9337: SSPI/GSSAPI with mismatched user names
От | Tom Lane |
---|---|
Тема | Re: BUG #9337: SSPI/GSSAPI with mismatched user names |
Дата | |
Msg-id | 9531.1393275398@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #9337: SSPI/GSSAPI with mismatched user names (Brian Crowell <brian@fluggo.com>) |
Ответы |
Re: BUG #9337: SSPI/GSSAPI with mismatched user names
|
Список | pgsql-bugs |
Brian Crowell <brian@fluggo.com> writes: > On Mon, Feb 24, 2014 at 2:09 PM, Brian Crowell <brian@fluggo.com> wrote: >> I humbly resubmit my ticket-in-the-startup-packet suggestion, which >> I'd hope would be easier, especially since any program not supplying >> it would fall back to the standard challenge auth mechanism. > Tell you what. > Our company is not to the point of needing anything like this, I was > just helping out the Npgsql people. But if we should get to the point > that we'd want it, would you accept patches that implemented this sort > of shortcut authentication? As a new feature it would need discussion, and I'm not real sure that it's sensible even in theory. In our model, until you've identified the relevant pg_hba.conf entry you don't know which Kerberos server to talk to to validate the ticket. 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. I suppose you could propose some additional configuration settings that would be looked at in advance of the pg_hba.conf lookup to allow extraction of a user name from a supplied ticket. However, that would greatly expand the potential for DOS attacks based on launching bogus startup packets at a postmaster (since the computation needed before rejecting a packet is greatly increased if we have to contact some Kerberos server). Not sure if that objection is fatal or not. regards, tom lane
В списке pgsql-bugs по дате отправления: