> >> 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.
>
> Hmm. I guess I was confusing this with the --with-krb-srvnam configure
> directive, and expecting that it ought to convert that from a
> frozen-at-configure value into a run-time-configuration variable.
> What is the relationship of these two values, anyway?
A service principal is often of the form something/hostname@REALM, and
by default in postgres, the "something" is postgres and as it is today,
hostname is what gethostbyname() returns.
A complete service principal might be: postgres/db.example.com@EXAMPLE.COM.
The --with-krb-srvname changes this.
> The documentation additions are pretty poor in both proposed patches;
> they do nothing to clear up any confusion.
Indeed, if you're not familiar with kerberos conventions this won't make
too much sense. Actually, the use of 'srvname' is kind of confusing. I
originally thought the hostname was compiled in by default.
I'd imagine most people wouldn't want to change it and if they did it
probably would be site wide.
Something like:
sets the hostname that the postgres server will require to be
used for service principals. This is combined with the value
specified at configure time with --with-krb-srvnam (defaulting
to postgres). Assuming the default of postgres, the service
principal would be of the form postgres/specified_hostname@REALM.
The default is to allow any service principal matching an entry
in the keytab
(or)
The default is the hostname of the postgres server.
depending on which patch. That would have cleared up the confusion for
me, anyway.
-Todd