Re: WIP: SCRAM authentication

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael.paquier@gmail.com>, David Steele <david@pgmasters.net>, Heikki Linnakangas <hlinnaka@iki.fi>, Bruce Momjian <bruce@momjian.us>, Greg Stark <stark@mit.edu>, Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-02-15T01:58:17Z
Lists: pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> How about we just say that the password in these old views always reads
>> out as '********' even when there is a password, and we invent new views
>> that carry real auth information?  (Hopefully in an extensible way.)

> I'd be alright with that approach, I'd just rather that any clients
> which actually want to read the password field be updated to look at the
> extensible and sensible base catalogs, and not some hacked up array that
> we shoved into that field.

Yeah, I'm good with that.  I just don't think the breakage needs to extend
to clients that aren't trying to read auth-related information.

BTW, if we haven't learned this lesson by now: I'm pretty sure that every
single one of these views is an attempt to emulate what *used* to be the
real base catalog, in some previous release.  Maybe we should stop
expecting clients to read the real catalog, ever, in favor of a sanitized
view?  Although I don't know exactly what that would lead to in terms of
what we'd expose that's different from what the base catalog is.  But it's
worth thinking about whether there is a way to avoid having this same
discussion again in five or ten years.

			regards, tom lane


Commits

  1. Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).