On Sun, Jul 19, 2015 at 8:56 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan <p...@heroku.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
