From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Subject: | Re: Arguable RLS security bug, EvalPlanQual() paranoia |
Date: | 2015-08-03 22:21:44 |
Message-ID: | CAM3SWZR4wB9ShMiEoAt=4whaFzB7qt-nFdi-Jnxgk2CTkOATgg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 3, 2015 at 3:07 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Thoughts? Trying to keep it straight-forward and provide a simple
> solution for users to be able to address the issue, if they're worried
> about it. Perhaps this, plus an additional paragraph which goes into
> more detail about exactly what's going on?
I'm still thinking about it, but I think you have the right idea here.
However, as the docs put it when talking about conventional access
controls and SELECT: "The use of FOR UPDATE or FOR SHARE requires
UPDATE privilege as well [as SELECT privilege] (for at least one
column of each table so selected)". I wonder if RLS needs to consider
this, too.
If you can just say that you don't have to worry about this when the
user has no right to UPDATE or DELETE the rows in the first place,
that makes it more practical to manage the issue. ISTM that as things
stand, you can't say that because RLS does not consider SELECT FOR
UPDATE special in any way.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Fabrízio de Royes Mello | 2015-08-04 00:12:48 | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |
Previous Message | Stephen Frost | 2015-08-03 22:07:26 | Re: Arguable RLS security bug, EvalPlanQual() paranoia |