Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: Non-superuser subscription owners
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: <66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel@j-davis.com>
Date: Sat, 27 Nov 2021 10:05:16 -0800
Cc: Amit Kapila <amit.kapila16@gmail.com>,
 Andrew Dunstan <andrew@dunslane.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Robert Haas <robertmhaas@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE7D7024-6723-4ACB-82AB-94F6A194BE0D@enterprisedb.com>
References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com>
 <c1c334a2-5d85-687f-f0dc-0ac8c422ca1a@dunslane.net>
 <CD02D159-7260-4247-888F-2CFA7AD3798D@enterprisedb.com>
 <6BB4451E-7B1B-474C-BD1F-DB7531E720C6@enterprisedb.com>
 <aa28945f9f348307c8ac833a937b5fca732668b8.camel@j-davis.com>
 <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com>
 <b6f6ed921b6e219875801857204b14bbc8782e5e.camel@j-davis.com>
 <CF56AC0D-7495-4E8D-A48F-FF38BD8074EB@enterprisedb.com>
 <CAA4eK1KHE_xmxk==CqTcTzceC_n00tRWBLm3DGUWhaaPTguz3A@mail.gmail.com>
 <1BB0A553-3FE9-4A91-A975-6F9D8C157FBD@enterprisedb.com>
 <CAA4eK1LBjtqHH2h4TO7FHG=FJRfygfkeEb7AFj-dh6rqg3xqUA@mail.gmail.com>
 <CC5DAC9C-F767-4256-BFEF-32D5A566D254@enterprisedb.com>
 <7C62876F-5D19-4B5C-96AC-5590B10A49B2@enterprisedb.com>
 <66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel@j-davis.com>
To: Jeff Davis <pgsql@j-davis.com>
Archived-At: 
 <https://www.postgresql.org/message-id/FE7D7024-6723-4ACB-82AB-94F6A194BE0D%40enterprisedb.com>
Precedence: bulk


> On Nov 24, 2021, at 4:30 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>=20
> We need to do permission checking for WITH CHECK OPTION and RLS. The
> patch right now allows the subscription to write data that an RLS
> policy forbids.

Thanks for reviewing and for this observation!  I can verify that RLS is =
not being honored on the subscriber side.  I agree this is a problem for =
subscriptions owned by non-superusers.

The implementation of the table sync worker uses COPY FROM, which makes =
this problem hard to fix, because COPY FROM does not support row level =
security.  We could do some work to honor the RLS policies during the =
apply workers' INSERT statements, but then some data would circumvent =
RLS during table sync and other data would honor RLS during worker =
apply, which would make the implementation not only wrong but =
inconsistently so.

I think a more sensible approach for v15 is to raise an ERROR if a =
non-superuser owned subscription is trying to replicate into a table =
which has RLS enabled.  We might try to be more clever and check whether =
the RLS policies could possibly reject the operation (by comparing the =
TO and FOR clauses of the policies against the role and operation type) =
but that seems like a partial re-implementation of RLS.  It would be =
simpler and more likely correct if we just unconditionally reject =
replicating into tables which have RLS enabled.

What do you think?

> A couple other points:
>=20
> * We shouldn't refer to the behavior of previous versions in the docs
> unless there's a compelling reason

Fair enough.

> * Do we need to be smarter about partitioned tables, where an insert
> can turn into an update?

Do you mean an INSERT statement with an ON CONFLICT DO UPDATE clause =
that is running against a partitioned table?  If so, I don't think we =
need to handle that on the subscriber side under the current logical =
replication design.  I would expect the plain INSERT or UPDATE that =
ultimately executes on the publisher to be what gets replicated to the =
subscriber, and not the original INSERT .. ON CONFLICT DO UPDATE =
statement.

> * Should we refactor to borrow logic from ExecInsert so that it's less
> likely that we miss something in the future?

Hooking into the executor at a higher level, possibly ExecInsert or =
ExecModifyTable would do a lot more than what logical replication =
currently does.  If we also always used INSERT/UPDATE/DELETE statements =
and never COPY FROM statements, we might solve several problems at once, =
including honoring RLS policies and honoring rules defined for the =
target table on the subscriber side.

Doing this would clearly be a major design change, and possibly one we =
do not want.  Can we consider this out of scope?

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company