>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
TL> Well, actually, the subtext of my question is that we now support
TL> what's effectively multiple VirtualHosts (see the listen_addresses
TL> parameter), and I was wondering if that means that
TL> krb_server_hostname needs to have an entry per listen_address in
TL> order to respond to the problem you see.
According to my reading of the MIT krb5 1.3 docs krb_server_hostname
should not need an entry per listen_address if NULL is passed in as the
server principal when call krb5_recvauth:
\begin{funcdecl}{krb5_recvauth}{krb5_error_code}{\funcinout}
[...]
The parameters \funcparam{server}, \funcparam{auth_context},
and \funcparam{keytab} are used by \funcname{krb5_rd_req} to obtain the
server's private key.
\begin{funcdecl}{krb5_rd_req}{krb5_error_code}{\funcinout}
[...]
\funcparam{server} specifies the expected server's name for the
ticket. If \funcparam{server} is NULL, then any server name will be
accepted if the appropriate key can be found, and the caller should
verify that the server principal matches some trust criterion.
However, I am suspicious of the docs because I am almost certain I've read
that before and wrote some code that relied on that behaviour but it
didn't work as expected and 'do the right thing'. ISTR possibly even to
the extent of a SEGV, but my memory is extemely hazy on this point.
Hence I'd really want to test actual code against MIT krb5 1.3 and 1.4.
Unfortunately the margin of this email is too small to provide space for
those tests :-)
I don't have time right now to investigate this behaviour further but I
will be revisiting this issue in relation to another project RSN. I will
endeavour to remember to report back if you so wish.
