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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема GSSAPI doesn't play nice with non-canonical host names
Дата
Msg-id 15223.1201478441@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: GSSAPI doesn't play nice with non-canonical host names  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: "Gevik Babakhani"
Дата:
Сообщение: Re: MSVC Build error
Следующее
От: Tom Lane
Дата:
Сообщение: SSL connections don't cope with server crash very well at all