On Fri, Feb 3, 2017 at 4:59 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 2 February 2017 at 18:48, Peter Eisentraut > <peter.eisentr...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers