Re: Patch to add Heimdal kerberos support
От | Tom Lane |
---|---|
Тема | Re: Patch to add Heimdal kerberos support |
Дата | |
Msg-id | 29767.1005616276@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch to add Heimdal kerberos support (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch to add Heimdal kerberos support
Re: Patch to add Heimdal kerberos support |
Список | pgsql-patches |
I said: > Well, it's not clear to me. Where did the ticket come from? Perhaps > we've already determined that you are who you say you are just by being > able to acquire the ticket. After doing a little light reading (RFC 1510...) it seems that what the Kerberos auth exchange actually gives you is confidence that the other party is the Kerberos principal named in the ticket you got from him. We don't use the claimed Postgres username in the process of acquiring the ticket, so there's no automatic cross-check as I was hoping. We must look at the principal name. The problem from our point of view is that a Kerberos principal name is a multi-part entity, and it's not entirely clear how to map that into a Postgres username. I'm moderately unhappy with the solution used in the code now: take the first name component, ignore all else, including the realm. This appears to mean that a server living in Kerberos realm k1 will happily accept people from different realms, eg joe@k2, without noticing that this is not the same person as joe@k1. Bad dog. It also seems that our present code may be using some long-deprecated Kerberos APIs --- for example, the krb5_recvauth man pages I can find on the net describe several more parameters than our code is expecting to pass. I suspect that that direct access to a field of the ticket is a hangover we should be able to get rid of. regards, tom lane
В списке pgsql-patches по дате отправления: