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
