Thread: krb5 authentication and multihomed server hosts
PostgreSQL-Version: 7.4.7
Operating-Sytem: Debian GNU/Linux 3.1 (sarge)
It is not always possible to use krb5 authentication to a server that is
listening on multiple interfaces other than to the 'primary' interface.
More specifically: src/backend/libpq/auth.c pg_krb5_init() fills in the
pg_krb5_server principal with a call to krb5_sname_to_principal with NULL
as the second argument (the hostname argument). This invokes the hostname
canonicalisation behaviour in the kerberos library which has insufficient
information to be able to return the correct answer in all cases.
zero-credibility:~# host zero-credibility.oucs.ox.ac.uk
zero-credibility.oucs.ox.ac.uk has address 163.1.2.14
zero-credibility:~# host pgsql-dev.oucs.ox.ac.uk
pgsql-dev.oucs.ox.ac.uk has address 163.1.2.37
zero-credibility:~# netstat -nie # check interfaces are up
Kernel Interface table
eth0 Link encap:Ethernet HWaddr 00:E0:81:63:D6:08
inet addr:163.1.2.14 Bcast:163.1.2.255 Mask:255.255.255.0
inet6 addr: fe80::2e0:81ff:fe63:d608/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4603401 errors:0 dropped:0 overruns:0 frame:0
TX packets:197179 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:342050931 (326.2 MiB) TX bytes:26094767 (24.8 MiB)
Base address:0xa000 Memory:f4020000-f4040000
eth0:37 Link encap:Ethernet HWaddr 00:E0:81:63:D6:08
inet addr:163.1.2.37 Bcast:163.1.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0xa000 Memory:f4020000-f4040000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:222060 errors:0 dropped:0 overruns:0 frame:0
TX packets:222060 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:94776903 (90.3 MiB) TX bytes:94776903 (90.3 MiB)
zero-credibility:~# netstat -natp | grep 5432 # check postmaster is listening
tcp 0 0 0.0.0.:5432 0.0.0.0:* LISTEN 25267/postmaster
zero-credibility:~# klist -k /etc/postgresql/krb5.keytab # confirm keytab contents
Keytab name: FILE:/etc/postgresql/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 postgres/pgsql-dev.oucs.ox.ac.uk@OX.AC.UK
3 postgres/pgsql-dev.oucs.ox.ac.uk@OX.AC.UK
[...flip to client...]
pod@plutonium$ psql -h pgsql-dev.oucs.ox.ac.uk template1 # try to connect
psql: Kerberos 5 authentication failed
pod@plutonium$ klist # confirm we got a service ticket
Ticket cache: FILE:/tmp/krb5cc_1000_rnx4Z0
Default principal: pod@OX.AC.UK
Valid starting Expires Service principal
07/26/05 09:48:01 07/26/05 19:48:01 krbtgt/OX.AC.UK@OX.AC.UK
07/26/05 13:26:33 07/26/05 19:48:01 postgres/pgsql-dev.oucs.ox.ac.uk@OX.AC.UK
[...back to server...]
zero-credibility:~# tail /var/log/postgresql/postgres.log
[...]
Jul 26 13:35:23 zero-credibility postgres[25963]: [1-1] LOG: connection received: host=129.67.100.155 port=33718
Jul 26 13:35:23 zero-credibility postgres[25963]: [2-1] LOG: Kerberos recvauth returned error -1765328240
Jul 26 13:35:23 zero-credibility postgres[25963]: [3-1] FATAL: Kerberos5 authentication failed for user "pod"
zero-credibility:~# grep -e -1765328240 /usr/include/krb5.h # what is that err?
#define KRB5KRB_AP_WRONG_PRINC (-1765328240L)
I append a patch that 'fixes' behaviour for the limited case where a
virtual_host is specified in /etc/postgresql/postgresql.conf. I'm not
sure it is possible to fix the INADDR_ANY case without changes to
krb5_recvauth() which is, of course, not your concern.
[...apply patch, run patched server...]
zero-credibility:~# grep -e virtual_host /etc/postgresql/postgresql.conf
virtual_host = '163.1.2.37'
[...try again on client...]
pod@plutonium$ psql -h pgsql-dev.oucs.ox.ac.uk template1
Welcome to psql 7.4.7, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
template1=> \q
--------------------
--- postgresql-7.4.7-old/src/backend/libpq/auth.c 2003-12-20 18:25:02.000000000 +0000
+++ postgresql-7.4.7/src/backend/libpq/auth.c 2005-07-25 19:55:26.000000000 +0100
@@ -216,8 +216,18 @@
return STATUS_ERROR;
}
- retval = krb5_sname_to_principal(pg_krb5_context, NULL, PG_KRB_SRVNAM,
+ if( VirtualHost && VirtualHost[0] )
+ {
+ char *host=VirtualHost;
+ while(*host==' ') host++; /* skip leading spaces (cf postmaster.c) */
+ retval = krb5_sname_to_principal(pg_krb5_context, host, PG_KRB_SRVNAM,
+ KRB5_NT_SRV_HST, &pg_krb5_server);
+ }
+ else
+ {
+ retval = krb5_sname_to_principal(pg_krb5_context, NULL, PG_KRB_SRVNAM,
KRB5_NT_SRV_HST, &pg_krb5_server);
+ }
if (retval)
{
ereport(LOG,
pod@herald.ox.ac.uk (pod) writes:
> PostgreSQL-Version: 7.4.7
> It is not always possible to use krb5 authentication to a server that is
> listening on multiple interfaces other than to the 'primary' interface.
> More specifically: src/backend/libpq/auth.c pg_krb5_init() fills in the
> pg_krb5_server principal with a call to krb5_sname_to_principal with NULL
> as the second argument (the hostname argument).
I see this has been changed in CVS tip, but I don't know enough about
Kerberos to know whether the change addresses your operational problem.
> I append a patch that 'fixes' behaviour for the limited case where a
> virtual_host is specified in /etc/postgresql/postgresql.conf.
VirtualHost is long gone, so this patch is of little help anyway. Could
you take a look at CVS or a recent nightly snapshot (look under dev/ on
the FTP servers) and see if your problem is fixed or not?
regards, tom lane
>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
TL> VirtualHost is long gone, so this patch is of little help anyway.
TL> Could you take a look at CVS or a recent nightly snapshot (look
TL> under dev/ on the FTP servers) and see if your problem is fixed or
TL> not?
Yeah, didn't think the patch was going to help much :-(. I'll feed it to
the Debian maintainer though, in case they're interested, since 7.4.7 is
what shipped in sarge.
A brief scan of src/backend/libpq/auth.c 1.127 make me think it will
behave similarly to my patched 7.4.7 when krb_server_hostname is specified
in the config file.
I'd have to actually test multiple listen_addresses and krb5_recvauth()
behaviour when the pg_krb5_server krb5_principal is NULL. I have a
horrible suspicion that this used to be broken in MIT krb5 but may not be
now. In any case, again, it's not your concern.
Thank you for your time.
pod@herald.ox.ac.uk (pod) writes:
> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> TL> VirtualHost is long gone, so this patch is of little help anyway.
> A brief scan of src/backend/libpq/auth.c 1.127 make me think it will
> behave similarly to my patched 7.4.7 when krb_server_hostname is specified
> in the config file.
> I'd have to actually test multiple listen_addresses and krb5_recvauth()
> behaviour when the pg_krb5_server krb5_principal is NULL. I have a
> horrible suspicion that this used to be broken in MIT krb5 but may not be
> now. In any case, again, it's not your concern.
Well, actually, the subtext of my question is that we now support what's
effectively multiple VirtualHosts (see the listen_addresses parameter),
and I was wondering if that means that krb_server_hostname needs to have
an entry per listen_address in order to respond to the problem you see.
regards, tom lane
>>>>> "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.
pod@herald.ox.ac.uk (pod) writes:
> 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.
Yes, please do. The krb_server_hostname functionality is new for PG
8.1, and there's still time to adjust it without creating compatibility
problems, if it doesn't do quite what is needed. I would guess that
we'd still consider changes in it for another month or two, so I hope
"RSN" is in that kind of time frame.
regards, tom lane