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

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Bug: RLS policy FOR SELECT is used to check new rows
Date: 2023-10-25 07:45:53
Message-ID: 7c54eb3c1f3a1017414ce399fae2a247c513740c.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2023-10-24 at 15:05 -0400, Stephen Frost wrote:
> On Tue, Oct 24, 2023 at 14:42 Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Tue, Oct 24, 2023 at 1:46 PM Jeff Davis <pgsql(at)j-davis(dot)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...
>
> Yes, having it be similar to a view WITH CHECK OPTION was intentional,
> also on not wishing for things to be able to disappear or to not get saved.
> The risk of a constraint possibly causing the leak of information is better
> than either having data just thrown away or having the constraint not
> provide the guarantee it’s supposed to …

Thanks everybody for looking and remembering.

I can accept that the error is intentional, even though it violated the
POLA for me. I can buy into the argument that an UPDATE should not make
a row seem to vanish.

I cannot buy into the constraint argument. If the table owner wanted to
prevent you from causing a constraint violation error with a row you
cannot see, she wouldn't have given you a FOR UPDATE policy that allows
you to perform such an UPDATE.

Anyway, it is probably too late to change a behavior that has been like
that for a while and is not manifestly buggy.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2023-10-25 08:05:08 RE: [PoC] pg_upgrade: allow to upgrade publisher node
Previous Message Alvaro Herrera 2023-10-25 07:45:44 Re: BUG #18167: cannot create partitioned tables when default_tablespace is set