Re: Arguable RLS security bug, EvalPlanQual() paranoia

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

In response to

Responses

Browse pgsql-hackers by date

  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