GSSAPI, SSPI - include_realm default
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
On 11/26/14 2:01 PM, Stephen Frost wrote:
As such, I'd like to propose changing the default to be
'include_realm=1'.
Sounds reasonable to me.
include_realm is supported back to 8.4, so affected users can set
include_realm=0 in their existing installations.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Peter Eisentraut (peter_e@gmx.net) wrote:
On 11/26/14 2:01 PM, Stephen Frost wrote:
As such, I'd like to propose changing the default to be
'include_realm=1'.Sounds reasonable to me.
include_realm is supported back to 8.4, so affected users can set
include_realm=0 in their existing installations.
Ah, yes, good point. Will include that suggestion also.
Thanks!
Stephen
On Wed, Nov 26, 2014 at 8:01 PM, Stephen Frost <sfrost@snowman.net> wrote:
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'.
Per our previous discussions, but to make sure it's also on record for
others, +1 for this suggestion.
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.
I suggest we also backpatch some documentation suggesting that people
manually change the include_realm parameter (perhaps also with a note
saying that the default will change in 9.5).
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Magnus Hagander (magnus@hagander.net) wrote:
On Wed, Nov 26, 2014 at 8:01 PM, Stephen Frost <sfrost@snowman.net> wrote:
This would be done for 9.5 and we would need to note it in the release
notes, of course.I suggest we also backpatch some documentation suggesting that people
manually change the include_realm parameter (perhaps also with a note
saying that the default will change in 9.5).
Agreed and will do (this was also suggested by Peter).
Thanks!
Stephen
* Magnus Hagander (magnus@hagander.net) wrote:
On Wed, Nov 26, 2014 at 8:01 PM, Stephen Frost <sfrost@snowman.net> wrote:
As such, I'd like to propose changing the default to be
'include_realm=1'.Per our previous discussions, but to make sure it's also on record for
others, +1 for this suggestion.
Patch attached which does this for master.
This would be done for 9.5 and we would need to note it in the release
notes, of course.I suggest we also backpatch some documentation suggesting that people
manually change the include_realm parameter (perhaps also with a note
saying that the default will change in 9.5).
I'll work on a patch for back-branches if everyone is alright with this
patch against master. Given my recent track record for changing
wording around, it seems prudent to get agreement on this first.
Thanks,
Stephen
Attachments:
include_realm_default_v1.patchtext/x-diff; charset=us-asciiDownload
From fe4d7a01f5d31fac565a8de2485cd9d113a9cbb4 Mon Sep 17 00:00:00 2001
From: Stephen Frost <sfrost@snowman.net>
Date: Fri, 5 Dec 2014 12:54:05 -0500
Subject: [PATCH] Change default for include_realm to zero
The default behavior for GSS and SSPI authentication methods has long
been to strip the realm off of the principal, however, this is not a
secure approach in multi-realm environments and the use-case for the
parameter at all has been superseded by the regex-based mapping support
available in pg_ident.conf.
Change the default for include_realm to be 'zero', meaning that we do
NOT remove the realm from the principal by default. Any installations
which depend on the existing behavior will need to update their
configurations (ideally by leaving include_realm on and adding a mapping
in pg_ident.conf). Note that the mapping capability exists in all
currently supported versions of PostgreSQL and so this change can be
done today. Barring that, existing users can update their
configurations today to explicitly set include_realm=0 to ensure that
the prior behavior is maintained when they upgrade.
This needs to be noted in the release notes.
Per discussion with Magnus and Peter.
---
doc/src/sgml/client-auth.sgml | 66 ++++++++++++++++++++++++++++---------------
src/backend/libpq/hba.c | 13 +++++++++
2 files changed, 57 insertions(+), 22 deletions(-)
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 7704f73..69517dd 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -943,15 +943,24 @@ omicron bryanh guest1
</para>
<para>
- Client principals must have their <productname>PostgreSQL</> database user
- name as their first component, for example
- <literal>pgusername@realm</>. Alternatively, you can use a user name
- mapping to map from the first component of the principal name to the
- database user name. By default, the realm of the client is
- not checked by <productname>PostgreSQL</>. If you have cross-realm
- authentication enabled and need to verify the realm, use the
- <literal>krb_realm</> parameter, or enable <literal>include_realm</>
- and use user name mapping to check the realm.
+ Client principals can be mapped to different <productname>PostgreSQL</>
+ database user names with <filename>pg_ident.conf</>. For example,
+ <literal>pgusername@realm</> could be mapped to just <literal>pgusername</>.
+ Alternatively, you can use the full <literal>username@realm</> principal as
+ the role name in <productname>PostgreSQL</> without any mapping.
+ </para>
+
+ <para>
+ <productname>PostgreSQL</> also supports a parameter to strip the realm from
+ the principal. This method is supported for backwards compatibility and is
+ strongly discouraged as it is then impossible to distinguish different users
+ with the same username but coming from different realms. To enable this,
+ set <literal>include_realm</> to zero. For simple single-realm
+ installations, <literal>include_realm</> combined with the
+ <literal>krb_realm</> parameter (which checks that the realm provided
+ matches exactly what is in the krb_realm parameter) would be a secure but
+ less capable option compared to specifying an explicit mapping in
+ <filename>pg_ident.conf</>.
</para>
<para>
@@ -993,10 +1002,13 @@ omicron bryanh guest1
<term><literal>include_realm</literal></term>
<listitem>
<para>
- If set to 1, the realm name from the authenticated user
- principal is included in the system user name that's passed through
- user name mapping (<xref linkend="auth-username-maps">). This is
- useful for handling users from multiple realms.
+ If set to 0, the realm name from the authenticated user principal is
+ stripped off before being passed through the user name mapping
+ (<xref linkend="auth-username-maps">). This is discouraged and is
+ primairly available for backwards compatibility as it is not secure
+ in multi-realm environments unless krb_realm is also used. Users
+ are recommended to leave include_realm set to the default (1) and to
+ provide an explicit mapping in <filename>pg_ident.conf</>.
</para>
</listitem>
</varlistentry>
@@ -1008,10 +1020,11 @@ omicron bryanh guest1
Allows for mapping between system and database user names. See
<xref linkend="auth-username-maps"> for details. For a Kerberos
principal <literal>username/hostbased@EXAMPLE.COM</literal>, the
- user name used for mapping is <literal>username/hostbased</literal>
- if <literal>include_realm</literal> is disabled, and
- <literal>username/hostbased@EXAMPLE.COM</literal> if
- <literal>include_realm</literal> is enabled.
+ user name used for mapping is
+ <literal>username/hostbased@EXAMPLE.COM</literal>, unless
+ <literal>include_realm</literal> has been enabled, in which case
+ <literal>username/hostbased</literal> is what is seen as the
+ system username when mapping.
</para>
</listitem>
</varlistentry>
@@ -1066,10 +1079,13 @@ omicron bryanh guest1
<term><literal>include_realm</literal></term>
<listitem>
<para>
- If set to 1, the realm name from the authenticated user
- principal is included in the system user name that's passed through
- user name mapping (<xref linkend="auth-username-maps">). This is
- useful for handling users from multiple realms.
+ If set to 0, the realm name from the authenticated user principal is
+ stripped off before being passed through the user name mapping
+ (<xref linkend="auth-username-maps">). This is discouraged and is
+ primairly available for backwards compatibility as it is not secure
+ in multi-realm environments unless krb_realm is also used. Users
+ are recommended to leave include_realm set to the default (1) and to
+ provide an explicit mapping in <filename>pg_ident.conf</>.
</para>
</listitem>
</varlistentry>
@@ -1079,7 +1095,13 @@ omicron bryanh guest1
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details.
+ <xref linkend="auth-username-maps"> for details. For a Kerberos
+ principal <literal>username/hostbased@EXAMPLE.COM</literal>, the
+ user name used for mapping is
+ <literal>username/hostbased@EXAMPLE.COM</literal>, unless
+ <literal>include_realm</literal> has been enabled, in which case
+ <literal>username/hostbased</literal> is what is seen as the
+ system username when mapping.
</para>
</listitem>
</varlistentry>
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index d43c8ff..1559ad2 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1406,6 +1406,19 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline, int line_num)
hbaline->ldapscope = LDAP_SCOPE_SUBTREE;
#endif
+ /*
+ * For GSS and SSPI, set the default value of include_realm to true.
+ * Having include_realm set to false is dangerous in multi-realm
+ * situations and is generally considered bad practice. We keep the
+ * capability around for backwards compatibility, but we might want to
+ * remove it at some point in the future. Users who still need to strip
+ * the realm off would be better served by using an appropriate regex in
+ * a pg_ident.conf mapping.
+ */
+ if (hbaline->auth_method == uaGSS ||
+ hbaline->auth_method == uaSSPI)
+ hbaline->include_realm = true;
+
if (strcmp(name, "map") == 0)
{
if (hbaline->auth_method != uaIdent &&
--
1.9.1
On 12/5/14 1:06 PM, Stephen Frost wrote:
I suggest we also backpatch some documentation suggesting that people
manually change the include_realm parameter (perhaps also with a note
saying that the default will change in 9.5).I'll work on a patch for back-branches if everyone is alright with this
patch against master.
I don't think backpatching this is necessary or appropriate.
First of all, this isn't even released, and it might very well change
again later. The right time to publicly notify about this change is not
before when 9.5 is released.
Also, it's not like people keep re-reading the old documentation in
order to get updated advice. It might very well be confusing if stable
documentation changes because of future events. Users who are
interested in knowing about changes in future releases should read the
release notes of those future releases.
My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases. So when 9.5 comes out and people update their
pg_hba.conf files for 9.5, those files will still work in old releases.
But the time to do those updates is then, not now.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Dec 9, 2014 10:52 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote:
On 12/5/14 1:06 PM, Stephen Frost wrote:
I suggest we also backpatch some documentation suggesting that people
manually change the include_realm parameter (perhaps also with a note
saying that the default will change in 9.5).I'll work on a patch for back-branches if everyone is alright with this
patch against master.I don't think backpatching this is necessary or appropriate.
First of all, this isn't even released, and it might very well change
again later. The right time to publicly notify about this change is not
before when 9.5 is released.Also, it's not like people keep re-reading the old documentation in
order to get updated advice. It might very well be confusing if stable
documentation changes because of future events. Users who are
interested in knowing about changes in future releases should read the
release notes of those future releases.My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases. So when 9.5 comes out and people update their
pg_hba.conf files for 9.5, those files will still work in old releases.
But the time to do those updates is then, not now.
I thought the idea was to backpatch documentation saying "it's a good idea
to change this value to x because of y". Not actually referring to the
upcoming change directly. And I still think that part is a good idea, as it
helps people avoid potential security pitfalls.
So not really a backpatch as so, rather a separate patch for the back
branches. (and people definitely reread the docs - since they deploy new
systems on the existing versions...)
/Magnus
* Peter Eisentraut (peter_e@gmx.net) wrote:
On 12/5/14 1:06 PM, Stephen Frost wrote:
I suggest we also backpatch some documentation suggesting that people
manually change the include_realm parameter (perhaps also with a note
saying that the default will change in 9.5).I'll work on a patch for back-branches if everyone is alright with this
patch against master.I don't think backpatching this is necessary or appropriate.
Sorry if that wasn't clear but the idea was to *just* backpatch the
documentation comments, not to change the default in back-branches.
First of all, this isn't even released, and it might very well change
again later. The right time to publicly notify about this change is not
before when 9.5 is released.Also, it's not like people keep re-reading the old documentation in
order to get updated advice. It might very well be confusing if stable
documentation changes because of future events. Users who are
interested in knowing about changes in future releases should read the
release notes of those future releases.My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases. So when 9.5 comes out and people update their
pg_hba.conf files for 9.5, those files will still work in old releases.
But the time to do those updates is then, not now.
The back-branches are being patched to discourage using the default
because it's not a secure approach. New users start using PG all the
time and so changing the existing documentation is worthwhile to ensure
those new users understand. A note in the release notes for whichever
minor release the change to the documentation shows up in would be a
good way to make existing users aware of the change and hopefully
encourage them to review their configuration.
If we don't agree that the change should be made then we can discuss
that, but everyone commenting so far has agreed on the change.
Thanks,
Stephen
* Magnus Hagander (magnus@hagander.net) wrote:
On Dec 9, 2014 10:52 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote:
On 12/5/14 1:06 PM, Stephen Frost wrote:
I suggest we also backpatch some documentation suggesting that people
manually change the include_realm parameter (perhaps also with a note
saying that the default will change in 9.5).I'll work on a patch for back-branches if everyone is alright with this
patch against master.I don't think backpatching this is necessary or appropriate.
First of all, this isn't even released, and it might very well change
again later. The right time to publicly notify about this change is not
before when 9.5 is released.Also, it's not like people keep re-reading the old documentation in
order to get updated advice. It might very well be confusing if stable
documentation changes because of future events. Users who are
interested in knowing about changes in future releases should read the
release notes of those future releases.My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases. So when 9.5 comes out and people update their
pg_hba.conf files for 9.5, those files will still work in old releases.
But the time to do those updates is then, not now.I thought the idea was to backpatch documentation saying "it's a good idea
to change this value to x because of y". Not actually referring to the
upcoming change directly. And I still think that part is a good idea, as it
helps people avoid potential security pitfalls.
I agree with this but I don't really see why we wouldn't say "hey, this
is going to change in 9.5." Peter's argument sounds like he'd rather we
not make any changes to the existing documentation, and I don't agree
with that, and if we're making changes then, imv, we might as well
comment that the default is changed in 9.5.
So not really a backpatch as so, rather a separate patch for the back
branches. (and people definitely reread the docs - since they deploy new
systems on the existing versions...)
Yes, I was going to write a different patch for the back-branches,
apologies if that wasn't clear. I'll see about drafting something up
soon as there doesn't seem to be any argument about the substance of the
proposed patch for master.
Thanks,
Stephen
On Tue, Dec 9, 2014 at 05:40:35PM -0500, Stephen Frost wrote:
I thought the idea was to backpatch documentation saying "it's a good idea
to change this value to x because of y". Not actually referring to the
upcoming change directly. And I still think that part is a good idea, as it
helps people avoid potential security pitfalls.I agree with this but I don't really see why we wouldn't say "hey, this
is going to change in 9.5." Peter's argument sounds like he'd rather we
not make any changes to the existing documentation, and I don't agree
with that, and if we're making changes then, imv, we might as well
comment that the default is changed in 9.5.
I agree with Peter --- it is unwise to reference a future released
feature in a backbranch doc patch. Updating the backbranch docs to add
a recommendation is fine.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Bruce Momjian (bruce@momjian.us) wrote:
On Tue, Dec 9, 2014 at 05:40:35PM -0500, Stephen Frost wrote:
I thought the idea was to backpatch documentation saying "it's a good idea
to change this value to x because of y". Not actually referring to the
upcoming change directly. And I still think that part is a good idea, as it
helps people avoid potential security pitfalls.I agree with this but I don't really see why we wouldn't say "hey, this
is going to change in 9.5." Peter's argument sounds like he'd rather we
not make any changes to the existing documentation, and I don't agree
with that, and if we're making changes then, imv, we might as well
comment that the default is changed in 9.5.I agree with Peter --- it is unwise to reference a future released
feature in a backbranch doc patch. Updating the backbranch docs to add
a recommendation is fine.
Alright, I don't agree but it's not worth the argument. I'll work on
the doc-update patch for the back-branches.
Thanks,
Stephen
On 12/9/14 5:40 PM, Stephen Frost wrote:
I agree with this but I don't really see why we wouldn't say "hey, this
is going to change in 9.5."
Well, for one thing, we don't even know if it's going to be called 9.5. ;-)
And there is always a chance for a technical reason popping up that we
might not make the change after all in 9.5.
I'd be fine with something more along the lines of "the default might
change in the future ... if you want to be future-proof, set it explicitly".
Let's see an actual patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Peter Eisentraut (peter_e@gmx.net) wrote:
On 12/9/14 5:40 PM, Stephen Frost wrote:
I agree with this but I don't really see why we wouldn't say "hey, this
is going to change in 9.5."Well, for one thing, we don't even know if it's going to be called 9.5. ;-)
Now that is certainly a very good point.
And there is always a chance for a technical reason popping up that we
might not make the change after all in 9.5.
I suppose.
I'd be fine with something more along the lines of "the default might
change in the future ... if you want to be future-proof, set it explicitly".
Sure, that'd work for me.
Let's see an actual patch.
Will do. Might be a few days before I get to it but I don't think
there's any cause for rush anyway.
Thanks,
Stephen
On Wed, Dec 10, 2014 at 4:53 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Dec 9, 2014 at 05:40:35PM -0500, Stephen Frost wrote:
I thought the idea was to backpatch documentation saying "it's a good idea
to change this value to x because of y". Not actually referring to the
upcoming change directly. And I still think that part is a good idea, as it
helps people avoid potential security pitfalls.I agree with this but I don't really see why we wouldn't say "hey, this
is going to change in 9.5." Peter's argument sounds like he'd rather we
not make any changes to the existing documentation, and I don't agree
with that, and if we're making changes then, imv, we might as well
comment that the default is changed in 9.5.I agree with Peter --- it is unwise to reference a future released
feature in a backbranch doc patch. Updating the backbranch docs to add
a recommendation is fine.
I am strongly in agreement with that principle as well.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Dec 9, 2014 at 05:38:25PM -0500, Stephen Frost wrote:
My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases. So when 9.5 comes out and people update their
pg_hba.conf files for 9.5, those files will still work in old releases.
But the time to do those updates is then, not now.The back-branches are being patched to discourage using the default
because it's not a secure approach. New users start using PG all the
time and so changing the existing documentation is worthwhile to ensure
those new users understand. A note in the release notes for whichever
minor release the change to the documentation shows up in would be a
good way to make existing users aware of the change and hopefully
encourage them to review their configuration.If we don't agree that the change should be made then we can discuss
that, but everyone commenting so far has agreed on the change.
Where are we on this?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce,
* Bruce Momjian (bruce@momjian.us) wrote:
On Tue, Dec 9, 2014 at 05:38:25PM -0500, Stephen Frost wrote:
My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases. So when 9.5 comes out and people update their
pg_hba.conf files for 9.5, those files will still work in old releases.
But the time to do those updates is then, not now.The back-branches are being patched to discourage using the default
because it's not a secure approach. New users start using PG all the
time and so changing the existing documentation is worthwhile to ensure
those new users understand. A note in the release notes for whichever
minor release the change to the documentation shows up in would be a
good way to make existing users aware of the change and hopefully
encourage them to review their configuration.If we don't agree that the change should be made then we can discuss
that, but everyone commenting so far has agreed on the change.Where are we on this?
Thanks for the reminder. I've not forgotten about it and will work on
crafting language in the next week or so.
Thanks again!
Stephen
Bruce, all,
* Bruce Momjian (bruce@momjian.us) wrote:
On Tue, Dec 9, 2014 at 05:38:25PM -0500, Stephen Frost wrote:
My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases. So when 9.5 comes out and people update their
pg_hba.conf files for 9.5, those files will still work in old releases.
But the time to do those updates is then, not now.The back-branches are being patched to discourage using the default
because it's not a secure approach. New users start using PG all the
time and so changing the existing documentation is worthwhile to ensure
those new users understand. A note in the release notes for whichever
minor release the change to the documentation shows up in would be a
good way to make existing users aware of the change and hopefully
encourage them to review their configuration.If we don't agree that the change should be made then we can discuss
that, but everyone commenting so far has agreed on the change.Where are we on this?
Patches for master and 9.4 attached. The 9.4 patch should cherry-pick
down to the other current releases just fine. Please provide any
comments or suggestions for changes. If all looks good, I'll push this
to change the default for 9.5 to be include_realm=1 and the
documentation updates to recommend it in back-branches.
Thanks!
Stephen
Attachments:
include_realm_recommendation9.4.patchtext/x-diff; charset=us-asciiDownload
From 6a0a7bb06dd461c4f2f11c55f30815bada6b2e10 Mon Sep 17 00:00:00 2001
From: Stephen Frost <sfrost@snowman.net>
Date: Mon, 27 Apr 2015 13:30:24 -0400
Subject: [PATCH] Recommend include_realm=1 in docs
As discussed, the default setting of include_realm=0 can be dangerous in
multi-realm environments because it is then impossible to differentiate
users with the same username but who are from two different realms.
Recommend include_realm=1 and note that the default setting may change
in a future version of PostgreSQL and therefore users may wish to
explicitly set include_realm to avoid issues while upgrading.
---
doc/src/sgml/client-auth.sgml | 41 ++++++++++++++++++++++++++++++++---------
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index d27dd49..9bb8a94 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -1000,7 +1000,12 @@ omicron bryanh guest1
If set to 1, the realm name from the authenticated user
principal is included in the system user name that's passed through
user name mapping (<xref linkend="auth-username-maps">). This is
- useful for handling users from multiple realms.
+ the recommended configuration as, otherwise, it is impossible to
+ differentiate users with the same username who are from different
+ realms. The default for this parameter is 0 (meaning to not include
+ the realm in the system user name) but may change to 1 in a future
+ version of <productname>PostgreSQL</productname>. Users can set it
+ explicitly to avoid any issues when upgrading.
</para>
</listitem>
</varlistentry>
@@ -1010,12 +1015,16 @@ omicron bryanh guest1
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details. For a Kerberos
- principal <literal>username/hostbased@EXAMPLE.COM</literal>, the
- user name used for mapping is <literal>username/hostbased</literal>
- if <literal>include_realm</literal> is disabled, and
- <literal>username/hostbased@EXAMPLE.COM</literal> if
- <literal>include_realm</literal> is enabled.
+ <xref linkend="auth-username-maps"> for details. For a GSSAPI/Kerberos
+ principal, such as <literal>username@EXAMPLE.COM</literal> (or, less
+ commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the
+ default user name used for mapping is
+ <literal>username</literal> (or <literal>username/hostbased</literal>,
+ respectfully), unless <literal>include_realm</literal> has been set to
+ 1 (as recommended, see above), in which case
+ <literal>username@EXAMPLE.COM</literal> (or
+ <literal>username/hostbased@EXAMPLE.COM</literal>)
+ is what is seen as the system username when mapping.
</para>
</listitem>
</varlistentry>
@@ -1073,7 +1082,12 @@ omicron bryanh guest1
If set to 1, the realm name from the authenticated user
principal is included in the system user name that's passed through
user name mapping (<xref linkend="auth-username-maps">). This is
- useful for handling users from multiple realms.
+ the recommended configuration as, otherwise, it is impossible to
+ differentiate users with the same username who are from different
+ realms. The default for this parameter is 0 (meaning to not include
+ the realm in the system user name) but may change to 1 in a future
+ version of <productname>PostgreSQL</productname>. Users can set it
+ explicitly to avoid any issues when upgrading.
</para>
</listitem>
</varlistentry>
@@ -1083,7 +1097,16 @@ omicron bryanh guest1
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details.
+ <xref linkend="auth-username-maps"> for details. For a SSPI/Kerberos
+ principal, such as <literal>username@EXAMPLE.COM</literal> (or, less
+ commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the
+ default user name used for mapping is
+ <literal>username</literal> (or <literal>username/hostbased</literal>,
+ respectfully), unless <literal>include_realm</literal> has been set to
+ 1 (as recommended, see above), in which case
+ <literal>username@EXAMPLE.COM</literal> (or
+ <literal>username/hostbased@EXAMPLE.COM</literal>)
+ is what is seen as the system username when mapping.
</para>
</listitem>
</varlistentry>
--
1.9.1
include_realm_default_v2.patchtext/x-diff; charset=us-asciiDownload
From ee6682b895b2f00ac89da6355b28960c358b8569 Mon Sep 17 00:00:00 2001
From: Stephen Frost <sfrost@snowman.net>
Date: Mon, 27 Apr 2015 12:40:07 -0400
Subject: [PATCH] Change default for include_realm to 0
The default behavior for GSS and SSPI authentication methods has long
been to strip the realm off of the principal, however, this is not a
secure approach in multi-realm environments and the use-case for the
parameter at all has been superseded by the regex-based mapping support
available in pg_ident.conf.
Change the default for include_realm to be '0', meaning that we do
NOT remove the realm from the principal by default. Any installations
which depend on the existing behavior will need to update their
configurations (ideally by leaving include_realm on and adding a mapping
in pg_ident.conf). Note that the mapping capability exists in all
currently supported versions of PostgreSQL and so this change can be
done today. Barring that, existing users can update their
configurations today to explicitly set include_realm=0 to ensure that
the prior behavior is maintained when they upgrade.
This needs to be noted in the release notes.
Per discussion with Magnus and Peter.
---
doc/src/sgml/client-auth.sgml | 74 +++++++++++++++++++++++++++++--------------
src/backend/libpq/hba.c | 13 ++++++++
2 files changed, 63 insertions(+), 24 deletions(-)
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index d27dd49..620ddc6 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -947,15 +947,24 @@ omicron bryanh guest1
</para>
<para>
- Client principals must have their <productname>PostgreSQL</> database user
- name as their first component, for example
- <literal>pgusername@realm</>. Alternatively, you can use a user name
- mapping to map from the first component of the principal name to the
- database user name. By default, the realm of the client is
- not checked by <productname>PostgreSQL</>. If you have cross-realm
- authentication enabled and need to verify the realm, use the
- <literal>krb_realm</> parameter, or enable <literal>include_realm</>
- and use user name mapping to check the realm.
+ Client principals can be mapped to different <productname>PostgreSQL</>
+ database user names with <filename>pg_ident.conf</>. For example,
+ <literal>pgusername@realm</> could be mapped to just <literal>pgusername</>.
+ Alternatively, you can use the full <literal>username@realm</> principal as
+ the role name in <productname>PostgreSQL</> without any mapping.
+ </para>
+
+ <para>
+ <productname>PostgreSQL</> also supports a parameter to strip the realm from
+ the principal. This method is supported for backwards compatibility and is
+ strongly discouraged as it is then impossible to distinguish different users
+ with the same username but coming from different realms. To enable this,
+ set <literal>include_realm</> to 0. For simple single-realm
+ installations, <literal>include_realm</> combined with the
+ <literal>krb_realm</> parameter (which checks that the realm provided
+ matches exactly what is in the krb_realm parameter) would be a secure but
+ less capable option compared to specifying an explicit mapping in
+ <filename>pg_ident.conf</>.
</para>
<para>
@@ -997,10 +1006,13 @@ omicron bryanh guest1
<term><literal>include_realm</literal></term>
<listitem>
<para>
- If set to 1, the realm name from the authenticated user
- principal is included in the system user name that's passed through
- user name mapping (<xref linkend="auth-username-maps">). This is
- useful for handling users from multiple realms.
+ If set to 0, the realm name from the authenticated user principal is
+ stripped off before being passed through the user name mapping
+ (<xref linkend="auth-username-maps">). This is discouraged and is
+ primairly available for backwards compatibility as it is not secure
+ in multi-realm environments unless krb_realm is also used. Users
+ are recommended to leave include_realm set to the default (1) and to
+ provide an explicit mapping in <filename>pg_ident.conf</>.
</para>
</listitem>
</varlistentry>
@@ -1010,12 +1022,15 @@ omicron bryanh guest1
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details. For a Kerberos
- principal <literal>username/hostbased@EXAMPLE.COM</literal>, the
- user name used for mapping is <literal>username/hostbased</literal>
- if <literal>include_realm</literal> is disabled, and
- <literal>username/hostbased@EXAMPLE.COM</literal> if
- <literal>include_realm</literal> is enabled.
+ <xref linkend="auth-username-maps"> for details. For a GSSAPI/Kerberos
+ principal, such as <literal>username@EXAMPLE.COM</literal> (or, less
+ commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the
+ user name used for mapping is
+ <literal>username@EXAMPLE.COM</literal> (or
+ <literal>username/hostbased@EXAMPLE.COM</literal>, respectfully),
+ unless <literal>include_realm</literal> has been set to 0, in which case
+ <literal>username</literal> (or <literal>username/hostbased</literal>)
+ is what is seen as the system username when mapping.
</para>
</listitem>
</varlistentry>
@@ -1070,10 +1085,13 @@ omicron bryanh guest1
<term><literal>include_realm</literal></term>
<listitem>
<para>
- If set to 1, the realm name from the authenticated user
- principal is included in the system user name that's passed through
- user name mapping (<xref linkend="auth-username-maps">). This is
- useful for handling users from multiple realms.
+ If set to 0, the realm name from the authenticated user principal is
+ stripped off before being passed through the user name mapping
+ (<xref linkend="auth-username-maps">). This is discouraged and is
+ primairly available for backwards compatibility as it is not secure
+ in multi-realm environments unless krb_realm is also used. Users
+ are recommended to leave include_realm set to the default (1) and to
+ provide an explicit mapping in <filename>pg_ident.conf</>.
</para>
</listitem>
</varlistentry>
@@ -1083,7 +1101,15 @@ omicron bryanh guest1
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details.
+ <xref linkend="auth-username-maps"> for details. For a SSPI/Kerberos
+ principal, such as <literal>username@EXAMPLE.COM</literal> (or, less
+ commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the
+ user name used for mapping is
+ <literal>username@EXAMPLE.COM</literal> (or
+ <literal>username/hostbased@EXAMPLE.COM</literal>, respectfully),
+ unless <literal>include_realm</literal> has been set to 0, in which case
+ <literal>username</literal> (or <literal>username/hostbased</literal>)
+ is what is seen as the system username when mapping.
</para>
</listitem>
</varlistentry>
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index a0f5396..c239385 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1376,6 +1376,19 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline, int line_num)
hbaline->ldapscope = LDAP_SCOPE_SUBTREE;
#endif
+ /*
+ * For GSS and SSPI, set the default value of include_realm to true.
+ * Having include_realm set to false is dangerous in multi-realm
+ * situations and is generally considered bad practice. We keep the
+ * capability around for backwards compatibility, but we might want to
+ * remove it at some point in the future. Users who still need to strip
+ * the realm off would be better served by using an appropriate regex in
+ * a pg_ident.conf mapping.
+ */
+ if (hbaline->auth_method == uaGSS ||
+ hbaline->auth_method == uaSSPI)
+ hbaline->include_realm = true;
+
if (strcmp(name, "map") == 0)
{
if (hbaline->auth_method != uaIdent &&
--
1.9.1
Bruce,
* Bruce Momjian (bruce@momjian.us) wrote:
On Tue, Dec 9, 2014 at 05:38:25PM -0500, Stephen Frost wrote:
My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases. So when 9.5 comes out and people update their
pg_hba.conf files for 9.5, those files will still work in old releases.
But the time to do those updates is then, not now.The back-branches are being patched to discourage using the default
because it's not a secure approach. New users start using PG all the
time and so changing the existing documentation is worthwhile to ensure
those new users understand. A note in the release notes for whichever
minor release the change to the documentation shows up in would be a
good way to make existing users aware of the change and hopefully
encourage them to review their configuration.If we don't agree that the change should be made then we can discuss
that, but everyone commenting so far has agreed on the change.Where are we on this?
Thanks for the prod on this. I've now committed the changes which were
discussed. Please let me know if you see any issues or have any
concerns.
Thanks again!
Stephen