Re: patch to add krb_server_hostname to postgresql.conf

> Todd Kover <kovert(at)omniscient(dot)com> writes:
>
> > The attached patch adds a directive to the config file,
> > krb_server_hostname that allows the hostname that service tickets
> > are obtained against to be different from the hostname of the db
> > server.
>
> Why is this necessary?

It's largely useful in combination with restricting the interfaces
listened to via the listen_addresses directive in the config file. As
the code works now you can only connect via kerberos with a service
principal derived from the hostname of the box rather than any dns name
associated with any of the box's interfaces.

For example, if the server is named server0.example.com, but the db is
bound to db.example.com via the listen_addresses directive, the pgsql
server won't authenticate properly.

Similarly, if server0.example.com is one interface and
server1.example.com is another, and the hostname is server.example.com
but doesn't correspond to any interfaces, connecting to neither will
work.

> If it is necessary, wouldn't something similar be needed at the
> client end as well?

No. The decision of which principal to obtain a service ticket for is
based on what it connects to.

In the first above example, if running:

psql -h server0.example.com

the client would obtain a service ticket for
postgres/server0.example.com. If running:

psql -h db.example.com

it would obtain a service ticket for postgres/db.example.com, and
without the directive I'm adding, it would fail to establish a
connection because the server wouldn't be expecting that. Of course,
adding the directive would make the first case fail and the second
pass. This works fine for our environment since we're binding to
db.example.com.

(as an aside, it's actually a bit more complicated then this since the
way the kerberos libraries are used, db.example.com is canonicalized, so
if it were a CNAME for server0.example.com it would do the right thing,
but we're using an A record).

> I'd have thought that host information would be established by some
> sort of system-wide configuration file, not by per-program options.

Different applications can use different service principals. The use
of the hostname in the principal name at all is an application-specific
decision. The krb5 api encourages it to be a DNS hostname pretty
strongly in the way it works, but it's not cast in stone.

However, other kerberos clients will accept using any kerberos principal
in the keytab but postgresql as shipped requires it to match the
hostname. If you want that behavior instead, then change pg_krb5_server
to NULL when calling krb5_recvauth in src/backend/libpq/auth.c and it
won't require that the hostnames match. (but it's still necessary for
something to match).

The second patch (kovert-krb5-patch-newbehavior.txt) makes the default
behavior to accept any principal in the keytab. This means that people
using kerberos will continue to work, but they'll be slightly more broad
in what they accept as a valid service principal (I suspect there's very
few people in the world who care about this since it still needs to be
something in the keytab).

I left the implementation of krb_server_hostname so that someone can
define this if they want. (and if they want to make it behave like
versions of pgsql up until now, they'd need to set it to the hostname).

The second patch's default case makes pgsql match the behavior of
eklogind (kerberized rlogind that ships with MIT kerberos) and the
gssapi/krb5-aware version of sshd and probably numerous other things.

> Also, the available documentation says that PG_KRB_SRVNAM is a
> service name, not a host name, so I feel like there's something wrong
> with your description of what you're doing.

indeed, there was something wrong with what I was doing. PG_KRB_SRVNAM
defaults to 'postgres' rather than the hostname. This was fallout from
when I was first developing the patch.

The absence of the krb_server_hostname config flag should have left the
default behavior in place, it wasn't. I just tested this patch against
both cases on a dev box and it works as expected.

both patches are against 8.0.0rc3. The first implements what I
originally was doing without changing the default, the second changes
the default to be more accepting and also implements the directive in
case someone wants to go back to the old behavior.

-Todd