GSSAPI doesn't play nice with non-canonical host names - Mailing list pgsql-hackers

From Tom Lane
Subject GSSAPI doesn't play nice with non-canonical host names
Date
Msg-id 15223.1201478441@sss.pgh.pa.us
Whole thread Raw
Responses Re: GSSAPI doesn't play nice with non-canonical host names  (Stephen Frost <sfrost@snowman.net>)
List 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@SSS.PGH.PA.US for postgres/localhost.localdomain@SSS.PGH.PA.US, Server not
foundin 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@SSS.PGH.PA.US for postgres/localhost.localdomain@SSS.PGH.PA.US, Server not
foundin 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@SSS.PGH.PA.US for krbtgt/LOCALDOMAIN@SSS.PGH.PA.US, Server not found in
Kerberosdatabase
 
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@SSS.PGH.PA.US for krbtgt/LOCALDOMAIN@SSS.PGH.PA.US, Server not found in
Kerberosdatabase
 
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@SSS.PGH.PA.US for krbtgt/US@SSS.PGH.PA.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@SSS.PGH.PA.US for krbtgt/US@SSS.PGH.PA.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@SSS.PGH.PA.US for krbtgt/PA.US@SSS.PGH.PA.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@SSS.PGH.PA.US for krbtgt/PA.US@SSS.PGH.PA.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@SSS.PGH.PA.US for krbtgt/PGH.PA.US@SSS.PGH.PA.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@SSS.PGH.PA.US for krbtgt/PGH.PA.US@SSS.PGH.PA.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


pgsql-hackers by date:

Previous
From: "Gevik Babakhani"
Date:
Subject: Re: MSVC Build error
Next
From: Tom Lane
Date:
Subject: SSL connections don't cope with server crash very well at all