Re: Bug: RLS policy FOR SELECT is used to check new rows - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Bug: RLS policy FOR SELECT is used to check new rows
Date
Msg-id CA+TgmobREcnCeuMCgJUwY2V4qzGuVUD+4pk0bNHAz=fiY_A8tQ@mail.gmail.com
Whole thread Raw
In response to Re: Bug: RLS policy FOR SELECT is used to check new rows  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Bug: RLS policy FOR SELECT is used to check new rows  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Oct 24, 2023 at 1:46 PM Jeff Davis <pgsql@j-davis.com> wrote:
> Perhaps the idea is that if there are constraints involved, the failure
> or success of an INSERT/UPDATE/DELETE could leak information that you
> don't have privileges to read.

My recollection of this topic is pretty hazy, but like Tom, I seem to
remember it being intentional, and I think the reason had something to
do with wanting the slice of a RLS-protect table that you can see to
feel like a complete table. When you update a row in a table all of
which is visible to you, the updated row can never vanish as a result
of that update, so it was thought, if I remember correctly, that this
should also be true here. It's also similar to what happens if an
updatable view has WITH CHECK OPTION, and I think that was part of the
precedent as well. I don't know whether or not the constraint issue
that you mention here was also part of the concern, but it may have
been. This was all quite a while ago...

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Bug: RLS policy FOR SELECT is used to check new rows
Next
From: Jacob Champion
Date:
Subject: Re: Row pattern recognition