Greetings, The include_realm default for GSSAPI and SSPI is currently 'include_realm=0', meaning that the realm is stripped off of the Kerberos principal (aka the 'system' username) prior to looking up the user in pg_authid.
This is fine in a single-realm environment but extremely dangerous
in a multi-realm environment, as user@REALMA is rarely the same as
user@REALMB. Worse, a given environment can go from single-realm to
multi-realm with relative ease and most administrators aren't going to
expect applications to have a problem with that change. Every other
Kerberos-enabled application which I'm aware of requires either the
full principal (including realm) be considered, or that the realm of
the principal matches the realm of the system (which is what OpenSSH
requires, as an example).
As such, I'd like to propose changing the default to be
'include_realm=1'.
Back when Kerberos support was originally added, we didn't have the
pg_ident regex-based mapping capability. Today, users who wish to
strip the realm off would be best served by configuring a mapping in
pg_ident.conf which strips off exactly the realm name (or names, if
they are multi-realm where the users actually are the same individuals
in multiple realms) instead of using 'include_realm=0'.
Users who really wish to strip off the realm for their environment
would still be able to add 'include_realm=0' to their pg_hba.conf.
We would recommend against that in the documentation, however, and
explain how it's unsafe. I would recommend that this be coached as
transistional support for users who wish to upgrade but don't want to
(further) change their configuration immediately, with the implication
that we might remove it some day.
This would be done for 9.5 and we would need to note it in the release
notes, of course.
Shipping an insecure pg_hba.conf as the default (with 'trust') works
because the distributions change it to a more secure setting anyway.
There's no similar option to change the default for include_realm
short of hacking the source code and documentation, which would be
much more invasive and likely invite complaints from users when their
configuration doesn't work the way the postgresql.org docs claim it
should.
Thoughts?
Thanks!
Stephen
signature.asc
Description: Digital signature
