Re: Arguable RLS security bug, EvalPlanQual() paranoia - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Arguable RLS security bug, EvalPlanQual() paranoia
Date
Msg-id CAM3SWZR4wB9ShMiEoAt=4whaFzB7qt-nFdi-Jnxgk2CTkOATgg@mail.gmail.com
Whole thread Raw
In response to Re: Arguable RLS security bug, EvalPlanQual() paranoia  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Arguable RLS security bug, EvalPlanQual() paranoia  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
List pgsql-hackers
On Mon, Aug 3, 2015 at 3:07 PM, Stephen Frost <sfrost@snowman.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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Arguable RLS security bug, EvalPlanQual() paranoia
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );