GSSAPI doesn't play nice with non-canonical host names

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: GSSAPI doesn't play nice with non-canonical host names
Date: 2008-01-28 00:00:41
Message-ID: 15223.1201478441@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Whilst trying to reproduce bug #3902 I noticed that the code doesn't
work with an abbreviated host name:

$ psql -l -h rh2.sss.pgh.pa.us
List of databases
... everything's fine ...

$ psql -l -h rh2
psql: GSSAPI continuation error: Unspecified GSS failure. Minor code may provide more information
GSSAPI continuation error: Unknown code krb5 7
$

Considering that my DNS system knows perfectly well what to resolve the
short name to, it seems reasonable that GSSAPI should be able to deal
with it. Looking into the KDC log shows that psql is trying everything
but the right thing for the hostname part of the server principal:

Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for postgres/localhost(dot)localdomain(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database
Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for postgres/localhost(dot)localdomain(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database
Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for krbtgt/LOCALDOMAIN(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database
Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for krbtgt/LOCALDOMAIN(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database
Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for krbtgt/US(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database
Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for krbtgt/US(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database
Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for krbtgt/PA(dot)US(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database
Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for krbtgt/PA(dot)US(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database
Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for krbtgt/PGH(dot)PA(dot)US(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database
Jan 27 18:41:19 rh2.sss.pgh.pa.us krb5kdc[3993](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.8: UNKNOWN_SERVER: authtime 1201474768, tgl(at)SSS(dot)PGH(dot)PA(dot)US for krbtgt/PGH(dot)PA(dot)US(at)SSS(dot)PGH(dot)PA(dot)US, Server not found in Kerberos database

This could be a configuration error on my part (I've never set up a
Kerberos server before today) but what it looks like to me is that
something in the GSSAPI library is assuming it's being handed a fully
qualified domain name. Perhaps pg_GSS_startup() shouldn't be using
just conn->pghost, but the fully resolved server domain name?

This is on Fedora 8, krb5-libs-1.6.2-9.fc8.x86_64, in case it matters.

While I'm complaining: that's got to be one of the least useful error
messages I've ever seen, and it's for a case that's surely going to be
fairly common in practice. Can't we persuade GSSAPI to produce
something more user-friendly? At least convert "7" to "Server not
found in Kerberos database"?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-01-28 00:37:42 Re: Proposed patch: synchronized_scanning GUC variable
Previous Message Gevik Babakhani 2008-01-27 23:09:51 Re: Proposed patch: synchronized_scanning GUC variable