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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> 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
> $

Testing w/ 8.3RC2, everything seems to be working fine here:

sfrost@snowman:/home/sfrost> psql -d postgres -h snowman
Welcome to psql 8.3RC2, the PostgreSQL interactive terminal.
...

sfrost@snowman:/home/sfrost> klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: sfrost@SNOWMAN.NET

Valid starting     Expires            Service principal
01/27/08 21:14:55  01/28/08 07:14:55  krbtgt/SNOWMAN.NET@SNOWMAN.NET       renew until 01/28/08 21:14:53
01/27/08 21:14:59  01/28/08 07:14:55  postgres/snowman.snowman.net@SNOWMAN.NET       renew until 01/28/08 21:14:53

It also picks up on the correct keytab entry on the first shot,
according to my KDC logs (and is what I would certainly expect):

Jan 27 21:14:53 snowman krb5kdc[5008]: AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.1.2: NEEDED_PREAUTH:
sfrost@SNOWMAN.NETfor krbtgt/SNOWMAN.NET@SNOWMAN.NET, Additional pre-authentication required 
Jan 27 21:14:55 snowman krb5kdc[5008]: AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.1.2: ISSUE: authtime 1201486495,
etypes{rep=16 tkt=16 ses=16}, sfrost@SNOWMAN.NET for krbtgt/SNOWMAN.NET@SNOWMAN.NET 
Jan 27 21:14:59 snowman krb5kdc[5008]: TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.1.2: ISSUE: authtime 1201486495,
etypes{rep=16 tkt=16 ses=16}, sfrost@SNOWMAN.NET for postgres/snowman.snowman.net@SNOWMAN.NET 

The first two lines are the krb5 preauth, followed by getting a
ticket-granting-ticket (both a result of my doing a 'kinit'), and then a
few seconds later the postgres/snowman.snowman.net@SNOWMAN.NET ticket
which was requested by psql when I attempted to connect.

> 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:

GSSAPI definitely should be handling it correctly, but the way it works
normally is perhaps a bit counter-intuitive: it resolves the reverse DNS
of the IP address to which it's connecting and uses that:

sfrost@snowman:/home/sfrost> host snowman.snowman.net
snowman.snowman.net has address 10.10.1.2
sfrost@snowman:/home/sfrost> host 10.10.1.2
2.1.10.10.in-addr.arpa domain name pointer snowman.snowman.net.

I'm guessing from the KDC logs that your 'rh2' is actually an alias in
/etc/hosts for 127.0.0.1, and localhost.localdomain, which is why it's
trying that first.  Putting in the FQDN is actually a work-around for
hosts which don't have a proper reverse DNS (we use it quite a bit when
we have remote servers that we use kerberos with but we don't control
the reverse DNS of), so I'm not too suprised that works.

As for why it doesn't eventually take whatever you gave it and tack it
on to the front of the local domain, I'm not sure.  There could be some
room for improvment here, certainly, but I'm pretty sure this is the
same behaviour the Kerberos auth mechanism would give you and isn't
suprising to people who use GSSAPI/Kerberos.

> 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?

I'm not sure if that would actually help or not and I wouldn't want to
confuse things for the GSSAPI library by passing it an FQDN when the
client didn't actually send one and perhaps bypass the reverse-DNS check
(which could break things- there are alot of cases where a given host
can have multiple hostnames while all of its IP addresses do resolve to
the same 'main' hostname which is what is used for Kerberos auth).

> 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"?

I agree, and have found it to be very frustrating while working w/
Kerberos in general.  I *think* there's a library which can convert
those error-codes (libcomm-err?), but I've not really looked into it
yet.
Thanks,    Stephen