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

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: 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 10:59:05
Message-ID: CAEZATCV+-U24XXRZ5jy1+pP_Y8KgxhR_8CaHLfi-dpQkUwsjRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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].

[1] https://github.com/postgres/postgres/commit/7d8db3e8f37aec9d252353904e77381a18a2fa9f

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michał Kłeczek 2023-10-24 11:22:53 A case for GIST supporting ORDER BY
Previous Message Drouvot, Bertrand 2023-10-24 10:05:09 Re: Synchronizing slots from primary to standby