Re: Enabling replication connections by default in pg_hba.conf

On Fri, Feb 3, 2017 at 4:59 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 2 February 2017 at 18:48, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> On 2/2/17 8:32 AM, Simon Riggs wrote:
>>> I think we should remove the "replication" false database concept in
>>> pg_hba.conf altogether and allow any valid pg_hba rule to invoke a
>>> replication connection, if one is requested. Roles would still need
>>> the REPLICATION capability before this would be allowed. Having both
>>> of those things doesn't materially improve security control.
>>
>> It's weirdly inconsistent now. You need a "replication" line in
>> pg_hba.conf to connect for logical decoding, but you can't restrict that
>> to a specific database because the database column in pg_hba.conf is
>> occupied by the "replication" key word.
>
> Agreed. Change needed.

That sounds really apealling indeed after thinking about its
implications. So we would simply authorize a WAL sender sending
"replication" to connect if the user name matches. That's in short
check_db() in hba.c.

>>> It would also be useful to be able prevent users with REPLICATION
>>> capability from connecting as normal users, if the are marked as
>>> NOLOGIN.
>>
>> That sounds useful.
>>
>> (Superusers not have the replication attribute by default is an
>> additional possible annoyance.)

Replication users are doing logins when requesting an access, that
seems inconsistent to me. And there are applications not defining a
replication role with NOLOGIN and still connecting via psql to perform
some sanity checks.
--
Michael