Re: Arguable RLS security bug, EvalPlanQual() paranoia

On Sun, Jul 19, 2015 at 8:56 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>> If you're using another well known MVCC database system that has RLS,
>> I imagine when this happens the attacker similarly waits on the
>> conflicting (privileged) xact to finish (in my example in the patch,
>> Bob's xact). However, unlike with the Postgres READ COMMITTED mode,
>> Mallory would then have her malicious UPDATE statement entirely rolled
>> back, and her statement would acquire an entirely new MVCC snapshot,
>> to be used by the USING security barrier qual (and everything else)
>> from scratch. This other system would then re-run her UPDATE with the
>> new MVCC snapshot. This would repeat until Mallory's UPDATE statement
>> completes without encountering any concurrent UPDATEs/DELETEs to her
>> would-be affected rows.
>>
>> In general, with this other database system, an UPDATE must run to
>> completion without violating MVCC, even in READ COMMITTED mode. For
>> that reason, I think we can take no comfort from the presumption that
>> this flexibility in USING security barrier quals (allowing subqueries,
>> etc) works securely in this other system. (I actually didn't check
>> this out, but I imagine it's true).
>
> Where are we on this?
>
> Discussion during pgCon with Heikki and Andres led me to believe that
> the issue is acceptable. The issue can be documented to help ensure
> that user expectation is in line with actual user-visible behavior.
> Unfortunately, I think that that will be a clunky documentation patch.

Perhaps I'm missing something, but it looks to me like Stephen has
done absolutely nothing about the many issues reported with the RLS
patch. I organized the open items list by topic on June 26th; almost
a month later, four more issues have been added to the section on RLS,
and none have been removed.

I think it is right that we should be concerned about this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company