GSSAPI, SSPI - include_realm default

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: GSSAPI, SSPI - include_realm default
Date: 2014-11-26 19:01:19
Message-ID: 20141126190119.GG28859@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)REALMA is rarely the same as
user(at)REALMB(dot) 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-26 19:10:22 Caching negative lookup results in typcache.c
Previous Message Pavel Stehule 2014-11-26 18:52:49 Re: proposal: plpgsql - Assert statement