Re: RLS with check option - surprised design

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RLS with check option - surprised design
Date: 2014-11-20 00:34:08
Message-ID: CAM3SWZSb6Ewa4HwcrMH2iX_HiHaQrGJoWbz7eMY3rAADc5_V1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 5, 2014 at 5:16 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> next a message:
>>
>> ERROR: new row violates WITH CHECK OPTION for "data"
>> DETAIL: Failing row contains (2014-10-05 12:28:30.79652, petr, 1000).
>>
>> Doesn't inform about broken policy.
>
> I'm guessing this is referring to the above policies and so my comments
> there apply.. One thing to note about this is that there is an active
> discussion about removing the 'DETAIL' part of that error message as it
> may be an information leak.

I should point out that there is an issue with the ON CONFLICT UPDATE
patch and RLS, as described here:

https://wiki.postgresql.org/wiki/UPSERT#RLS

I think it'll be possible to prevent the current information leak that
my example illustrates (by making sure that there is an appropriate
predicate associated with the auxiliary UPDATE plan, like any other
UPDATE). After all, the auxiliary UPDATE accepts a WHERE clause,
subject only to a few restrictions that are not relevant for the
purposes of appending security quals.

I actually spent over a day trying to figure out how to make this
work, but gave up before the most recent revision, V1.4 was submitted.
I guess I'll have to look at the problem again soon. I don't grok RLS,
but offhand I think simply not including the DETAIL message might be
good enough to fix my case. Maybe you have an opinion on that.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-11-20 00:52:16 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Previous Message Tom Lane 2014-11-19 23:29:05 Re: proposal: plpgsql - Assert statement