Robert, As I mentioned up thread, I'm out until the 27th. I have posted a patch which I will push to fix the copy.c issue, and I have already stated that I'll address the statistics issue. Further, Joe has also been working on issues but he was out of pocket last week attending a conference.
I'm happy to work up a documentation patch for this when I get back. Thanks! Stephen On Tuesday, July 21, 2015, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Jul 19, 2015 at 8:56 PM, Peter Geoghegan <p...@heroku.com > <javascript:;>> wrote: > > On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan <p...@heroku.com > <javascript:;>> 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 > >
