From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical replication access control patches |
Date: | 2017-03-22 02:38:06 |
Message-ID: | 69006e21-c1d2-4582-7cc1-f4087b9c644e@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/20/17 15:10, Petr Jelinek wrote:
> Hmm but REPLICATION role can do basebackup/consume wal, so how does
> giving it limited publication access help? Wouldn't we need some
> SUBSCRIPTION role/grant used instead for logical replication connections
> instead of REPLICATION for this to make sense?
Since we're splitting up the pg_hba.conf setup for logical and physical
connections, it would probably not matter.
But just to think it through, how could we split this up sensibly?
Here is the complete list of things that rolreplication allows:
- create/drop replication slot
- pg_logical_slot_get_changes() and friends
- connect to walsender
For logical replication, we could slice it up this way:
- new user attribute allowing the creating of logical replication slots
- store owner of slot, allow drop and get based on ownership
- allow anyone to connect as walsender
Another problem is that the walsender command to create a replication
slot allows you to load an arbitrary plugin.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-03-22 02:50:12 | Replication status in logical replication |
Previous Message | Peter Geoghegan | 2017-03-22 02:28:09 | Re: WIP: [[Parallel] Shared] Hash |