Re: Bug: RLS policy FOR SELECT is used to check new rows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Bug: RLS policy FOR SELECT is used to check new rows
Date: 2023-10-24 15:59:06
Message-ID: 572918.1698163146@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Tue, 24 Oct 2023 at 09:36, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>> I'd say that this error is wrong. The FOR SELECT policy should be applied
>> to the WHERE condition, but certainly not to check new rows.

> Yes, I had the same thought recently. I would say that the SELECT
> policies should only be used to check new rows if the UPDATE has a
> RETURNING clause and SELECT permissions are required on the target
> relation.

> In other words, it should be OK to UPDATE a row to new values that are
> not visible according to the table's SELECT policies, provided that
> the UPDATE command does not attempt to return those new values. That
> would be consistent with what we do for INSERT.

> Note, that the current behaviour goes back a long way, though it's not
> quite clear whether this was intentional [1].

I'm fairly sure that it was intentional, but I don't recall the
reasoning; perhaps Stephen does. In any case, I grasp your point
that maybe we should distinguish RETURNING from not-RETURNING cases.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema 2023-10-24 16:03:48 Add new for_each macros for iterating over a List that do not require ListCell pointer
Previous Message Tom Lane 2023-10-24 15:42:15 Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges