From: Josh Berkus <josh@agliodbs.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: SCRAM authentication
Date: Mon, 10 Aug 2015 12:21:55 -0700
Message-ID: <55C8F9D3.1070600@agliodbs.com> (raw)
In-Reply-To: <WM!2d0bf57fcc95de904ae58822c67d8c7add007ffeac486e39ae3e6275fb88f194d6680e0fd1124a22a6d9b80436974993!@asav-3.01.com>
References: <55192AFE.6080106@iki.fi>
<CAB7nPqRB_Z2B7Lz96iHbHUQBQLwmUtj64hXu0u7mMZjpSk8UUg@mail.gmail.com>
<CAB7nPqRBtLOT=g3q2-uYE=NbBdtkLubvDbV6wfCUp3hubpa6dg@mail.gmail.com>
<CA+TgmoZ0XxXZeGa0f1uwaCN-FCjFsAJZdJgioeesdhfR7jmEhg@mail.gmail.com>
<55C4FCC2.3000503@iki.fi>
<CAB7nPqRWYJmw+qJrawP=h2J5s6LFea3NUb10VJJjdBNr1Wz=+g@mail.gmail.com>
<CA+TgmoazGS0TpAtrFw+ft1UVUevBBXew5Lo6b1jtozgykpy5PA@mail.gmail.com>
<55C63B1E.2040101@iki.fi>
<CA+TgmoYQ=8BR87xgGkEWs8HJSe3KQh5v4fq+bZ2SAZhAnH3MtQ@mail.gmail.com>
<WM!2607bf41b9a89b33119972f5b4afde40079604473d0e477f1dc436a9fa9e91fbe0abb7b542ebd7beba5c4d754eca070e!@asav-3.01.com>
<55C79F0A.90601@agliodbs.com>
<CAB7nPqTkUnQ+TtXRs0ueAYcbVR+auhyjc5CQ7d1BBKJujsmP_Q@mail.gmail.com>
<WM!2d0bf57fcc95de904ae58822c67d8c7add007ffeac486e39ae3e6275fb88f194d6680e0fd1124a22a6d9b80436974993!@asav-3.01.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 08/09/2015 07:19 PM, Michael Paquier wrote:
>> ... during my exchange with Michael, I was thinking about the bug
>> > potential of taking the password field and multiplexing it in some way,
>> > which is significant. There is a definite risk of "making this too
>> > complicated" and we'll need to contrast that against ease-of-migration,
>> > because complicated mechanisms tend to be less secure due to user error.
> Sure. That's why I am all in for adding a compatibility GUC or similar
> that enforces the removal of old verifier types after marking those as
> deprecated for a couple of years as there's surely a significant risk
> to keep old passwords around or bad pg_hba entries. Still we need IMO
> a way for a user to save multiple verifiers generated from a client to
> manage carefully the password verifier aging, deprecations and support
> removal.
That still falls under the heading of "possibly too complicated" though.
As I see it, there's two potential migration paths:
1. Allow multiple verifiers for each login role (Heikki's plan).
2. Set verifier type per login role.
(2) has the advantage of not requiring a bunch of new scaffolding
(although it will require a little) and thus being less likely to
introduce new bugs. It also doesn't require adding new catalog
structures which are really only needed for the migration period, and
after which will become a wart (i.e. having multiple verifiers per login
role).
In real migration terms, though, (2) has some major drawbacks in terms
of making migration much harder.
a) it won't work for Heroku and other 1-login-per-database hosting.
b) moving to multiple roles from single roles per app is a painful
process currently.
For (a), one could argue that these are good candidates for "all at
once" migrations, and that moving to SCRAM will depend on the host
supporting it. Someone from Heroku could speak up here.
For (b), there are a lot of things we could do to make migrating to a
multiple-role infra much easier for users, which would continue to be
useful even after the migration to SCRAM is history:
* remove the role requirement for ALTER DEFAULT PRIVILEGES, and ...
* add ALTER ROLE ___ ALTER DEFAULT OWNER, a command which sets the
default owner of newly created objects by that login role to a different
role of which they are a member. Alternatively, add a way to make a
default SET ROLE whenever a login role logs in.
These two changes, or changes like them that serve the same purpose,
would allow us to prescribe the following migration path for most users:
1. add a new login role which is a member of the old login role and uses
SCRAM;
2. set the defaults for that role so that its objects and permissions
belong to the parent role;
3. move all applications to using SCRAM and the new role;
4. disable logins on the old, parent role.
It's currently (2) which is painfully difficult, and could be made less
so via the two features recommended above.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: josh@agliodbs.com, michael.paquier@gmail.com, robertmhaas@gmail.com, hlinnaka@iki.fi
Subject: Re: WIP: SCRAM authentication
In-Reply-To: <55C8F9D3.1070600@agliodbs.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox