| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Non-superuser subscription owners |
| Date: | 2022-01-08 17:14:59 |
| Message-ID: | 3c86885b0facc66eede94113123c1c3be39837fe.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 2022-01-08 at 15:35 +0530, Amit Kapila wrote:
> On Sat, Jan 8, 2022 at 1:01 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> >
> > On Sat, 2022-01-08 at 12:27 +0530, Amit Kapila wrote:
> > > For Update/Delete, we do read the table first via
> > > FindReplTupleInLocalRel(), so is there a need to check ACL_SELECT
> > > before that?
> >
> > If it's logically an update/delete, then I think ACL_UPDATE/DELETE
> > is
> > the right one to check. Do you have a different opinion?
> >
>
> But shouldn't we do it the first time before accessing the table?
I'm not sure I follow the reasoning. Are you saying that, to logically
replay a simple DELETE, the subscription owner should have SELECT
privileges on the destination table?
Is there a way that a subscription owner could somehow exploit a DELETE
privilege to see the contents of a table on which they have no SELECT
privileges? Or is it purely an internal read, which is necessary for
any ordinary local DELETE/UPDATE anyway?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-01-08 17:37:49 | Re: Non-superuser subscription owners |
| Previous Message | Amit Kapila | 2022-01-08 11:26:21 | Re: Logging replication state changes |