Amit Kapila <amit.kapil...@gmail.com> wrote: > On Tue, May 10, 2022 at 12:16 AM Euler Taveira <eu...@eulerto.com> wrote: > > > > On Mon, May 9, 2022, at 11:09 AM, Antonin Houska wrote: > > > > Now that the user can specify rows and columns to be omitted from the > > logical > > replication [1], I suppose hiding rows and columns from the subscriber is an > > important use case. However, since the subscription connection user (i.e. > > the > > user specified in the CREATE SUBSCRIPTION ... CONNECTION ... command) needs > > SELECT permission on the replicated table (on the publication side), he can > > just use another publication (which has different filters or no filters at > > all) to get the supposedly-hidden data replicated. > > > > The required privileges were not relaxed on publisher after the row filter > > and > > column list features. It is not just to "create another publication". Create > > publications require CREATE privilege on databases (that is *not* granted to > > PUBLIC).If you have an untrusted user that could bypass your rules about > > hidden > > data, it is better to review your user privileges. > > > > Also, to create a subscription (which combines multiple publications > to bypass rules), a user must be a superuser. So, isn't that a > sufficient guarantee that users shouldn't be able to bypass such > rules?
My understanding is that the rows/columns filtering is a way for the *publisher* to control which data is available to particular replica. From this point of view, the publication privileges would just make the control complete. -- Antonin Houska Web: https://www.cybertec-postgresql.com
