Re: Enabling replication connections by default in pg_hba.conf

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Enabling replication connections by default in pg_hba.conf
Date: 2017-02-02 19:59:04
Message-ID: CANP8+jKhD=H51OOZGVwcuAmbfKRUrjSbyV=2G7cryoqCQ6=Cfg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> However, you would still want a way to configure a user for logical
> decoding for any database but no physical replication, or vice versa.
> Just getting rid of the replication key word would prevent that, I think.

We currently have REPLICATION to mean "physical replication".

I think if we have another capability for logical replication then we
would be able to easily allow one or the other, or both, so I don't
see a problem here that forces us to keep pg_hba.conf the way it is.

>> 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.)

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jimmy Yih 2017-02-02 20:18:22 possible self-deadlock window after bad ProcessStartupPacket
Previous Message Andres Freund 2017-02-02 19:52:39 Re: Time to up bgwriter_lru_maxpages?