From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: Allow peer/ident to fall back to md5? |
Date: | 2014-10-29 06:39:49 |
Message-ID: | 20141029063949.GA400178@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 29, 2014 at 10:52:38AM +0800, Craig Ringer wrote:
> On 10/29/2014 10:45 AM, Tom Lane wrote:
> > Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> >> At pgconf-eu Álvaro and I were discussing the idea of allowing 'peer'
> >> and 'ident' authentication to fall back to md5 if the peer/ident check
> >> failed.
> >
> > I think it would be acceptable to define *new* auth modes that work
> > that way. I'm violently against redefining the meaning of existing
> > pg_hba.conf entries like this: it's not terribly hard to imagine
> > cases where it'd be a security problem, and even if you claim it isn't,
> > people will get bent out of shape if they think you're poking holes
> > in their oh-so-carefully-chosen authentication arrangements.
Switching from today's "peer" to the proposed method in a given installation
can indeed open a security hole. If you accept peer authentication only,
quality of account passwords is irrelevant. Using this mode requires setting
a strong password or no password at all.
> There's no point adding a usability improvement that's off by default.
>
> Distros can still enable it, though, and they're what I'm interested in.
> Nobody uses PostgreSQL's initdb default for pg_hba.conf ('trust') anyway.
Switching away from "trust" has been a safe call for distributions, because
every other method is strictly less permissive. "md5_or_peer" would be
strictly more permissive than either "md5" or "peer", so a distribution
switching to the new mode would be betting that the extra usability makes up
for folks overlooking the change and getting a security hole. (I think the
care needed to vet a switch from md5 to md5+peer is less than that needed to
vet a switch from peer to md5+peer.)
> I don't care in the slightest how it's spelled; these:
>
> peer
> peer with_md5_fallback
> peer md5_fallback=on
> peer_or_md5
Think about making this an option of the "peer" method that allows trying
subsequent pg_hba.conf lines when "peer" fails. Call it something like
"continue" or "sufficient". pg_hba.conf would have:
local all all peer continue
local all all md5
This lets you pair peer authentication with methods other than md5.
Thanks,
nm
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-10-29 08:24:20 | Re: WAL format and API changes (9.5) |
Previous Message | Amit Kapila | 2014-10-29 05:06:43 | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |