Re: Allow peer/ident to fall back to md5?

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

In response to

Responses

Browse pgsql-hackers by date

  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 ]